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in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 
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can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
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Foreword 

This Technical Specification (TS) has been produced by Joint Technical Conmiittee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 



Introduction 



IP Datacast is an end-to-end broadcast system for delivery of any types of digital content and services using IP-based 
mechanisms. An inherent part of the IPDC system is that it comprises a unidirectional DVB broadcast path and a 
bi-directional mobile/cellular interactivity path. IPDC is thus a platform for convergence of services from 
mobile/cellular and broadcast/media domains. 
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Scope 



The present document gives implementation guidelines on the use of the electronic service guide in IP Datacast over 
DVB-H system [1] to [8] for the announcement of services to the terminal. 

The present document intends in particular to guide implementers of IP Datacast over DVB-H Services, Servers and 
Terminals to make best use of the specification IP Datacast over DVB-H: Electronic Service Guide TS 102 471 [1]. The 
document is structured into three main clauses, some of them addressing particular groups of readers. Clause 5 provides 
an overview of the ESG datamodel which might be of interest for all readers. The following clause 6 describe typical 
business and usage scenarios of service delivery over broadcast and related instantiation examples of the ESG 
datamodel. Accordingly clause 6 is especially relevant for service implementers. Clause 7 provides guidelines for the 
terminal behaviour which might be of interest in particular to terminal implementers. Clause 8 provides ESG delivery 
guidelines for those implementing DVB IPDC headend systems. 

As those main clauses have particular groups of readers in focus and it should be possible to read those clauses 
independently of each other. However, it might wise to read the guideline in whole if the reasoning of implementation 
guidelines in particular clauses are of interest. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

- if it is accepted that it will be possible to use all future changes of the referenced document for the purposes 
of the referring document; 

- for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 471: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic 

Service Guide (ESG)". 

[2] Void. 

[3] ETSI TS 102 472: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content 

Delivery Protocols". 
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[4] ETSI TS 102 474: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Service 

Purchase and Protection" . 

[5] ETSI TS 102 470: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Program 

Specific Information (PSI)/Service Information (SI)". 

[6] ETSI TS 102 005: "Digital Video Broadcasting (DVB); Specification for the use of Video and 

Audio Coding in DVB services delivered directly over IP protocols". 

[7] Void. 

[8] Void. 

[9] Void. 

[10] Void. 

[11] Void. 

[12] ETSI TS 102 822-3-1: "Broadcast and On-line Services: Search, select, and rightful use of content 

on personal storage systems ("Broadcast and On-line Services: Search, select, and rightful use of 
content on personal storage systems ("TV- Anytime"); Part 3: Metadata; Sub-part 1: Phase 1 - 
Metadata schemas". 

[13] lANA: "Internet Multicast Addresses". 

NOTE: See http://www.iana.org/assignments/multicast-addresses . 

[14] lANA: "Internet Protocol Version 6 Multicast Addresses". 

NOTE: See http://www.iana.org/assignments/ipv6-multicast-addresses . 

[15] lANA: "Port Numbers". 

NOTE: See http://www.iana.org/assignments/port-numbers . 

[16] IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1". 

[17] IETF RFC 2327: "SDP: Session Description Protocol". 

[18] W3C Recommendation (2nd May 2001): "XML Schema". 

[19] ISO/IEC 15938-5: Multimedia Content Description Interface - Part 5: Multimedia Description 

Schemes. 

[20] Namespaces in XML 1.0 (Second Edition). 

NOTE: See http://www.w3.org/TR/REC-xml-names/ . 

[21] ETSI TS 102 822-3-2: "Broadcast and On-line Services: Search, select, and rightful use of content 

on personal storage systems ("Broadcast and On-line Services: Search, select, and rightful use of 
content on personal storage systems ("TV- Anytime"); Part 3: Metadata; Sub-part 2: System 
aspects in a uni-directional environment" . 

[22] IETF RFC 3629: "UTF-8, a transformation format of ISO 10646". 

[23] IETF RFC 2396: "Uniform Resource Identifiers (URI): Generic Syntax". 

[24] IETF RFC 1738: "Uniform Resource Locators (URL)" . 

[25] IETF RFC 2326: "Real Time Streaming Protocol (RTSP)" . 

[26] IETF RFC 2368: "The mailto URL scheme". 

[27] ISO/IEC 13818-1: "Generic coding of moving pictures and associated audio information: 

Systems". 
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[28] lANA: "MIME Media Types". 

NOTE: See at http://www.iana.org/assignments/media-types . 

[29] Void. 

[30] Void. 

[31] DVB Video Codec classification Scheme 2007 . 

NOTE: See http://www.dvb.org/. 

[32] DVB Audio Codec classification Scheme, www.dvb.org/metadata/2007/AudioCodecCS.xml. 

[33] DVB HowRelated classification Scheme 2007. 

NOTE: See http://www.dvb.org/. 

[34] IETF RFC 2806: "URLs for Telephone Calls". 

[35] IETF RFC 3550: "A Transport Protocol for Real-Time AppHcations" . 

2.2 Informative references 

[36] ETSI TS 102 468: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Set of 

Specifications for Phase 1 " . 

[37] ETSI TR 102 473: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Use Cases and 

Services". 

[38] ETSI TR 102 469: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Architecture". 

[39] ETSI TS 102 591 : "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content 

Delivery Protocols (CDP) Implementation Guidelines". 

[40] ETSI TR 102 377: "Digital Video Broadcasting (DVB); DVB-H Implementation Guidelines". 

[41] ETSI TS 126 234: "Transparent end-to-end packet-switched streaming service (PSS); Protocols 

and Codecs (3GPP TS 26.234)". 

[42] 3GPP2 TS C.S0046: "3G Multimedia streaming Service". 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 
acquisition information: information necessary to acquire a service or content 
content: atomic content part of the service described, and scheduled separately 
DVB-H Burst: burst of an elementary stream 

NOTE: Elementary streams are delivered in bursts due to time slicing in DVB-H. 
elementary stream: stream of transport packets within a transport stream sharing a common Packet Identifier (PID) 

NOTE: The elementary stream definition differs from the one defined in MPEG-2 (ISO/IEC 13818-1 [27]). 
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ESG auxiliary data: ESG data, which is referenced from an instance of the XML based data model, e.g. an SDP file, 
an HTML page or a PNG file 

NOTE: Even though SDP files can be considered as ESG auxiliary data, it is possible to transport them within the 
ESG fragment stream or as files within a FLUTE session. 

ESG container: structure to group ESG data into one transport object for delivery purposes 

ESG fragment: fragment of ESG data delivered in the ESG fragment stream and referred to by a fragment reference in 
the encapsulation structure 

NOTE: Namely an ESG fragment can be an ESG XML fragment, ESG auxiliary data or private auxiliary data. 

ESG fragment stream: stream of ESG fragments which contributes to the same ESG on receiver end 

NOTE: With respect to the transport layer this ESG fragment stream can be compiled from several transport 
streams, e.g. IP streams. 

ESG fragment type: category of ESG fragment e.g. ESG XML fragment, ESG auxiliary data or private auxiliary data 

ESG init container: ESG container carrying data structures for initialization, such as the ESG init message and the 
ESG main fragment 

ESG init message: initialization information to decode ESG fragments 

ESG XML fragment: ESG fragment of an XML instance which is an instantiation of a datatype 

NOTE: A limited set of ESG XML fragment types have been defined in TS 102 471 [1]. 

ESG XML fragment type: according to the ESG data model defined in TS 102 471 [1] the ESG XML fragment type is 
a category of ESG XML fragments 

NOTE: The ESG XML fragment types are defined based on the ContextPath which identifies an element and its 
datatype in an XML instance. These ContextPaths and the related datatypes are declared in table 6.2 of 
TS 102 471 [1] or in the Decoderlnit. 

interactive channel: connection over a bidirectional network including a return channel from the terminal 

IP platform: set of IP flows managed by an organisation 

NOTE: The IP platform represents a harmonized IP address space that has no address collisions. The concept of 
IP platforms is described in more detail in TS 102 470 [5]. 

IP flow: flow of IP datagrams each sharing the same IP source and destination address 

ESG session partition declaration: tells the terminal, how the ESG is partitioned in ESG Sessions, what are the 
partitioning criteria for each session 

private auxiliary data: data of which the format is not specified in TS 102 471 [1] 

purchase channel: purchase system, through which a service may be purchased 

purchase information: information to display to the user that a service needs to be purchased and the information that 
is necessary to access and acquire rights to consume a service or content 

purchase item: service bundle to which pricing information is attached 

schedule event: broadcast event which is described separately 

service: offer from a service provider and has media content related to it 

service: a service offering e.g. Broadcast TV Channel, soap opera service 

service bundle: group of services composed respectively offered by a single party 
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textual ESG XML fragment: part of an ESG XML instance document used for information interchange 

NOTE: It contains a single topmost element, i.e. one of the eight elements listed as ESG XML fragment types in 
table 6.2 of TS 102 471 [1] or a private ESG XML fragment declared in the textual Decoderlnit. 

transport flow: flow of IP datagrams identified by source IP-address, destination IP-address (either multicast or 
unicast), port and protocol in use 

NOTE: IP Flow is composed of one or more transport flows. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



3G 


3^ Generation 


3GPP 


3^^ Generation Partnership Project 


3GPP2 


3^^ Generation Partnership Project 2 


ALC 


Asynchronous Layered Coding 


AUX Data 


Auxiliary Data 


AVorAA^ 


AudioA^isual 


BCRO 


Broadcast Right Object 


CA 


Conditional Access 


GDP 


Content Delivery Protocol 


DNS 


Domain Name Service 


DRM 


Digital Right Management 


DVB 


Digital Video Broadcasting 


DVB-H 


Digital Video Broadcast - Handheld 


ESG 


Electronic Service Guide 


FDT 


File DeHvery Table 


EEC 


Forward Error Correction 


FLUTE 


File deLivery over Unidirectional Transport 


GZIP 


GnuZIP 


HTML 


HyperText Markup Language 


HUP 


HyperText Transfer Protocol 


lANA 


Internet Assigned Numbers Authority 


ID 


IDentifier 


IP 


Internet Protocol 


IPDC 


IP DataCast 


KMS 


Key Management System 


LCT 


Layered Coding Transport 


MIME 


Multipurpose Internet Mail Extensions 


MPE 


Multi Protocol Encapsulation 


MPE-FEC 


Multiprotocol Encapsulation - Forward Error Correction 


MPEG 


Moving Picture Expert Group 


MSS 


Multimedia Streaming Service 


OSF 


Open Security Framework 


PEK 


Program Encryption Key 


PID 


Packet IDentifier 


PNG 


Portable Network Graphics 


PSI/SI 


Program Specific Information/Service Information 


PSS 


Packet switched Streaming Service 


RFC 


Request For Comments 


RI 


Rights Issuer 


RO 


Rights Object 


ROAP 


Rights Object Acquisition Protocol 


RTCP 


Real-time Transport Control Protocol 


RTP 


Real-time Transport Protocol 


SDP 


Session Description Protocol 


SEK 


Service Encryption Key 


SOC 


Service Operation Centre 


SPP 


Service Purchase and Protection 


TDT 


Time and Date Table 
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TEK 

TO 

TOI 

TSI 

TV 

URI 

URL 

UTC 

UTF 

WEB 

XML 



Traffic Encryption Key 
Transport Object 
Transport Object Identifier 
Transport Session Identifier 
Television 

Uniform Resource Identifier 
Uniform Resource Locator 
Coordinated Universal Time 
Unicode Transformation Format 
last part of world wide WEB 
extensible Markup Language 



Examples 



The examples represent a particular way to instantiate an ESG to announce services described in the use cases. These 
examples are seen be good practice for these particular use cases. 

The examples, e.g. example instantiations of use cases, are marked with borders and grey background colour, see 
below. 

This is an example. 



5 Overview 

In this clause an overview of the data model as specified in TS 102 471 [1] is given. This overview comprises the 
objectives of the ESG data model specification, an overview of the specified ESG XML fragments, the references 
between them and strategies of data model instantiations for a particular set of use cases. 

In figure 5.1 a graphical representation of the data model is depicted. In this diagram each defined ESG XML fragment 
is represented by an labelled block. The references between the fragments are depicted as arrows in the direction the 
reference is declared. 

The data model as specified in TS 102 471 [1] has been designed to support a known set of common use cases. It is 
anticipated that the data model will require extensions in the future to support additional use cases. 



ServiceBundle 



0..n 



/\ 



0..1 



Purchase 



0..n 



PurchaseChannel 



0..n 



Service 



1 



ScheduleEvent 



0..n 




Acquisition 



"— Content 



Figure 5-1 : Block diagram of the ESG data model specified in TS 102 471 [1] 

5.1 Objectives of the ESG data model 

The ESG is primarily user attractor data, enabling the user to select and acquire content (acquisition information and 
purchase information have some exceptions to identify the related content respectively the related purchase 
information). 
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For a valid ESG instance it is not mandated to instantiate a particular fragment type. However the present document 
gives a guideline what fragments are relevant to support dedicated functionality respectively use case and how to 
instantiate the dedicated fragments. 

5.1.1 Design goals 

The ESG data model was design with the following goals in mind, so as to simplify the implementation. 

• small number of references to: 

a) limit the number of ways of representing a use case; 

b) to unify the processing; 

c) limit computational complexity. 

• small number of ESG XML fragment types to represent the core information required by the use cases 
identified for phase 1 . 

5.2 ESG fragment types 

In this clause the ESG fragment types defined in TS 102 471 [1] are introduced and their purpose is described. 

5.2.1 Service bundle fragment 

The service bundle fragment is used to group one or more services. The service bundle fragment can then be referenced 
by a purchase fragment enabling the purchase of rights to the set of services forming the service bundle. 

This is an optional fragment type, however at least one service bundle fragment must be present if a purchase fragment 
is available. 

5.2.2 Service fragment 

The service fragment enables the definition of a service offering, Where a service offering may be for example: 

• a streaming service; 

• a download service; 

• a combination of streaming and download. 

The service fragment provides descriptive and possibly visual information which may be used to attract a user to 
consume the service, and control information to enable a terminal to configure itself for consumption of the service (this 
is achieved via a reference to one or more acquisition fragments). 

For display efficiency of selectable services to the end user, it is recommended that there is one service fragment per 
service. 

NOTE: Content described by content fragments can be part of multiple services e.g. a highlight service. 

5.2.3 Schedule event fragment 

The schedule event fragment defines a period of time during which one content item is transmitted on the referenced 
streaming service. It can also define a period of time during which one or more content items are transmitted on the 
referenced file download service. 
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In both cases the time period is described by the elements PubHshedStartTime and PubHshedEndTime. Although the 
instantiation of PubHshedStartTime is optional, it is recommended to use it. PubHshedEndTime is optional and might 
not be present if the PubHshedEndTime is identical to the PubHshedStartTime of the consecutive schedule event of the 
described service assuming the schedule events are ordered in ascending order of PubHshedStartTime. However as 
ScheduleE vents can overlap for instance in the case of download content it is safer to always specify 
PubHshedStartTime and PubHshedEndTime. 

It is recommended that PubHshedStartTime and PubHshedEndTime are specified as Coordinated Universal Time (UTC) 
and to signal this explicitly by adding a "Z " to the dateTime string e.g. "2006-03-02T20:15:00Z". If this is not the case 
the time shift has to be specified according to XML schema [18]. 

This schedule event fragment may for example describe: 

• a traditional TV program; 

• one or more files available during the defined period on the FLUTE carousel. 

A content fragment describing the content item available during the scheduled event is identified via the element 
ContentFragmentRef. 

In addition the schedule event fragment may reference one or more acquisition fragments which enables the terminal to 
configure itself, for consumption of the event. 

The PubHshedStartTime and PubHshedEndTime of schedule event fragments can be used to infer the lifetime of a 
service. If the services availability is not discernable from the available schedule events, then it is recommended that a 
schedule event fragment that has no ContentFragmentRef element, is used to define the lifetime of the service. 

NOTE: The times used within the ESG fragments only declare published times and so it is not recommended to 
use these values to control acquisition. These published times are declared in UTC where the current time 
can be inferred from the TDT available within the transport stream carrying the ESG service. In addition 
there is a sampling clock carried within an RTCP sender reports that are used by the player to perform 
playout of the content. The "t=" fields in the SDP files may refer to this clock (see clause 5.1.2.1 of 
TS 102 591 [39]). The clock carried within RTCP sender reports may be independent of that signalled in 
the TDT. 

5.2.4 Content fragment 

The content fragment provides metadata about a content item. This content item may be a video and/or audio asset, or 
an interactive application. A content item is the smallest entity in the understanding of a non technical person e.g. a 
video composed from audio and video or an interactive application. 

The metadata is used to provide information to the user about the content of a schedule event respectively of a service. 

There is one content fragment for every content item. The content fragment may be referenced from, zero, one or 
several schedule event fragments. In addition a content fragment may make a reference to zero or more service 
fragments on which the content will be available. This reference may be used to indicate the service on which the 
content will be available even if a schedule event referring to this content is not available yet. 



5.2.5 Acquisition fragment 



The acquisition fragment provides information required for the consumption of the content referenced by a service or 
schedule event fragment. Specifically the acquisition fragment contains the SDP or the location of an SDP stream which 
carries the SDP. 

For services containing streamed media such as TV services it is recommended that at least one default acquisition 
fragment is referenced by a service fragment, with additional optional acquisition fragments being referenced from 
achedule event fragments, to signal additional options to those signalled within the services default acquisition. 

The default acquisition fragment is assumed to describe the continuously available set of media components that form 
the service. 
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In situations where additional media components are available (e.g. additional audio track) for a given schedule event, 
these are signalled by the schedule event fragment referencing an acquisition fragment that describes the media 
components that are available for the event. 

In the case of schedule event related acquisition fragments, the ContentLocation element if present in the 
ScheduleEvent fragment signals the entry point for the consuming application. The contentMimeType attribute within 
the AcquisitionType is used to determine the primary MIME type of the file serving as entry point to be delivered 
within a given session and to determine the application that is able to consume the files. 

If such indication can not be given by the MIME type then the contentMimeType attribute should be an empty string. 

EXAMPLE: contentMimeType = "" 

It is recommended to use the MIME types registered by lANA [28] or those defined in the IPDC specifications. Not 
complying to this recommendation of using MIME types may result in interoperability problems as terminals might not 
know how to process the related content. 

As an example in a webcast service the ContentLocation element may be set to "http:/foo.htm" and the 
contentMimeType may be set to "text/html" to indicate that the entry point is a HTML page, even though a large 
number of the files delivered may be images used within the HTML page. 

NOTE: This recommendation assumes that all entry points in the references to the acquisition fragment are of the 
described MIME type. 

Ultimately only the FDT provides the MIME type associated with each file delivered through the Content-Type 
attribute, which is mandatory for FLUTE when used in IP Datacast over DVB-H. 

5.2.6 Purchase fragment 

The purchase fragment is an entity which provides information necessary to gain access to a particular set of services. 
This information is composed of both attractor information and data required by the referenced SPP system to enable 
the purchase of rights to consume the set of services. 

5.2.7 Purchase channel fragment 

The purchase channel fragment provides information about a service provider offering service bundles for purchase. 
This information includes a description of the provider and its contact points (e.g. telephone number, URL) that can be 
displayed to the user, or used by the terminal for an automatic purchase. Additional information that is specific to the 
key management system used by the provider can also be included in this fragment. 

5.3 Mapping of use cases to fragments and fragment 
references 

In this clause an overview of common use cases, their concepts and how the relate to concepts in the ESG datamodel is 
given. A more elaborated discussion of business and usage scenarios is provided in clause 6. 

Signalling of availability of a TV Channel: 

• The concept of a TV channel maps in the data model to a concept of a service. 

• To signal the availability of a TV channel, a service fragment is instantiated. 
Signalling the availability of a TV Channel with multiple options e.g. multiple languages: 

• An instantiation of a generic acquisition fragment or acquisition fragments covering the primary option 
(language) or primary options (languages), respectively. 

• An instantiation of separate acquisition fragment covering the supplemental option referred to by the Schedule 
fragment. 
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Signalling that a TV broadcaster or service operator is offering multiple channels or multiple services: 
• The bundle of services is signalled by instantiating a service bundle fragment. 

The service bundle fragment contains references to one or multiple service fragments. 



• 



• 



The service bundle fragment can have different purchase fragments attached to, e.g. to enable the purchase 
over different purchase systems. 

Signalling that a network operator or TV broadcaster adds a new offer based on an existing service e.g. a soap opera 
service: 

• The new offer is signalled by instantiating a new service fragment. 

• As the new offer is based on an already existing service, the newly instantiated schedule event fragments of 
the new service refers to existing content fragments. 

• Optional also a new service bundle and purchase fragment might be signalled. 
Signalling that a mobile network operator provides a service bundle of existing third party services: 

• The new service bundle is signalled by instantiating a new service bundle fragment referencing existing 
service fragments. Optionally a new purchase fragment might be instantiated to allow the purchase of rights to 
consume the set of services. 

5.4 Use of Classification sciiemes 

Classification schemes provide the mechanism for defining and describing a set of terms used within an ESG instance. 
IPDC over DVB-H has defined a number of classification schemes that it recommends for use within an IPDC over 
DVB-H system, classification schemes are uniquely identified via the uri attribute declared in the ClassificationScheme 
element. 

The IPDC over DVB-H specification allows the delivery of classification schemes as part of the ESGMain fragment. 
However it is recommended that the terminal holds a representation of commonly referenced classification schemes 
used within an ESG instance. These classification schemes are used by the terminal to: 

• provide a human readable representation of the term to the end user e.g. name of the genre term or icon; 

• infer the position of a term within the term hierarchy. This may be used by the terminal for example to return 
all content descriptions which are from the term "Sport". The terminal will use the hierarchy to search for all 
content descriptions which have a genre field set to "Sport" or have a genre field which is a descendent of the 
"Sport" term. 

For more information on the use of classification schemes, how they may be extended, and how an element can 
reference a term within a classification scheme refer to ISO/IEC 15938-5 [19]. 



5.4.1 PurchaseType and QuantityUnit 



In this clause a recommendation for classification schemes which can be used for the controlled terms in PurchaseType 
and QuantityUnit of the purchase fragment is given. 

It is recommended to use the classification scheme urn:tva:metadata:cs:PurchaseTypeCS:2004 for the controlled terms 
in PurchaseType as defined in TS 102 471 [1]. 

It is recommended to use the classification scheme urn :tva: metadata: cs:UnitTypeCS: 2004 for the controlled terms in 
QuantityUnit as defined in TS 102 471 [1]. 
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5.4.2 RoleType 



In this clause, a recommendation for a role classification scheme is given which can be used for the "role" attribute of 
the "Character" element within the "CreditsList" element of the content fragment. 

It is recommended to use the TVARoleCS classification scheme uri="urn:tva:metadata:cs:TVARoleCS:2005", specified 
in TS 102 822-3-1 [12]. In particular the use of terms imported by the TVARoleCS classification scheme from the 
MPEG-7 RoleCS classification scheme uri= " urn: mpeg:mpeg7:cs:RoleCS: 2001" is recommended. The other terms from 
the TVARoleCS classification scheme could be used. 

5.4.3 GenreType 

In this clause a recommendation of a classification schemes that can be used within the GenreType of the 
ServiceBundle, the service or the content fragment. 

A number of genre references may be made within a single fragment to signal, the intended audience, main genre, and 
secondary genre. 

The following example shows how an educational, biology content item targeted at children is represented. 



<Content contentID="dvbipdc : //example . com/ContentlOO " > 

<Title xml :lang="en">Content Item 100</Title> 

<!-- Main genre = 'Education' --> 

<Genre type= 'main' href = "urn: tva : metadata : cs : ContentCS : 2005 :3.1.3.6.2"/> 

<! --secondary genre = 'Nature/Natural sciences/Biology ' --> 

<Genre type= ' secondary' href = "urn: tva : metadata : cs : ContentCS : 2 005 : 3 . 1 . 6 . 2 . !"/> 

<! --Intended Audience = 'Children' --> 

<Genre type= ' other ' href ="urn: tva :metadata : cs : IntendedAudienceCS : 2005 : 4 . 2 . !"/> 

<Duration>PT5M</Duration> 
</Content> 



In the case of primary and secondary genre it is recommended to use the terms defined in the third or fourth layer of the 
classification scheme urn:tva:metadata:cs:ContentCS:2005 as defined in TS 102 822-3-1 [12]. 

For instance the fourth layer term "football (soccer)" with termld="3.2.3.12" can be used to signal football genre. 

For the intended audience it is recommended to use the terms defined in the third layer of the classification scheme 
urn:tva:metadata:cs:IntendedAudienceCS:2005 as defined in TS 102 822-3-1 [12]. 

For instance the third layer term "children" with termld="4.2.1" can be used to signal that the content or service is 
targeted at children. 

5.4.4 ParentalRating 

The data model permits the ParentalRating to be based on either a minimum age criterion or as a term within a 
classification scheme that represents a rating scheme applicable within a geographical region. However with 
deployments covering multiple geographical regions the implementor should be aware that there is typically no direct 
mapping between a rating scheme and minimum age. 

The following example shows how the parental rating CS can be used to signal that the content is applicable to all 
within Italy. 



<Content contentID="dvbipdc : //example . com/Content3 " > 
<Title xml : lang="en" >Content Item 3</Title> 
<Genre href =" urn: tva : metadata : cs : ContentCS :2005:1.4.5"/> 
< Parent alGuidance> 

<mpeg7 : ParentalRating href = 'urn:dvb: ipdc:cs : ParentalGuidanceCS :2 005 : ITA. 1.1' /> 
<mpeg7 : Region>IT</mpeg7 : Region> 
</ Parent alGuidance> 
<Duration>PT15M</Duration> 
</Content> 



Annex A contains a recommended classification scheme for commonly used rating schemes. 
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5.4.5 HowRelated 



The HowRelated element which is a child of the RelatedMaterial element found within the ServiceBundle, content, and 
service fragments, is used to defined how the referenced content is semantically associated to the service, 
ServiceBundle or content. 

The following examples shows how the RelatedMaterial can be used to signal a link to a web site at which the user can 
obtain recommendations about other content similar to the described one, which may be of interest to him. 



<Content contentID="dvbipdc : //example . com/Content3 " > 
<Title xml : lang="en" >Content Item 3</Title> 
<Genre href = "urn: tva : metadata : cs rContentCS :2 005 : 1 .4 . 5"/> 
<RelatedMaterial> 

<HowRelated href= ' urn: tva rmetadata : cs rHowRelatedCS : 2007 : 6 ' /> 
<MediaLocator> 

<mpeg7 :MediaUri>http : //www. example . com/Recommendation/Content3</mpeg7 :MediaUri> 
</MediaLocator> 
< /RelatedMaterial > 
<Duration>PT15M</Duration> 
</Content> 



It is recommended to use the classification scheme urn:tva:metadata:cs:HowRelatedCS:2007 as defined in annex B. 

5.4.6 Audio video codec 

The audio video codecs used within a service are declared using the CodecCharacteristics (video) and codec (audio) 
elements within the acquisition fragment. 

Annex C contains a recommended classification scheme for audio and video codecs as specified in TS 102 005 [6]. 

The following is an example acquisition fragment containing a video and audio component. 



<Acquisition contentMimeType= "video/H264 " acquisitionID= "dvbipdc : //example . com/Acquisition/Channell " > 
<ComponentDescription> 
<ComponentCharacteristic xsi : type="VideoComponentType" > 
<CodecCharacteristic> 

<Codec href="urn:dvb:cs:VideoCodecCS:2 006 : 1 . 1 .2"/> 
</CodecCharacteristic> 
<FrameRate>2 5</FrameRate> 
</ComponentCharacteristic> 

<Component Characteristic xsi : type="AudioComponentType" > 
<Codec href="urn:dvb:cs:AudioCodecCS:2 006 : 1 .3 .2"/> 
<Language >en< /Language > 
</ComponentCharacteristic> 

<SessionDescription xsi : type="SDPRef Type" > 
<SDPStream> 

<! [CDATA[v=0 
o=example . com 751092616 751111042 IN 1P4 10.45.2.30 
s=SDP Delivery for Channell 
t = 

a=f lute-ch: 1 

m=application 12345 FLUTE/UDP 
C=1N 1P4 239.255.255.102/127 
a=flute-tsi: 98 7654 32 
]]> 

</SDPStream> 
<SDPURl>http: //example. com/defaultSDP</SDPURl> 
</SessionDescription> 
</ComponentDescription> 
</Acquisition> 



5.4.7 Service type 



The service type CS is used to signal the type of service that is being described. The terminal may then use this 
information if desired to filter the set of displayed services. It is possible to define multiple service types within a 
service fragment. When this is done it is assumed that one of the definitions defines the type of content available within 
the service, and the other defines the type of transport used by the service. 

It is recommended to use the classification scheme um:dvb:ipdc:esg:cs:ServiceTypeCS as defined in clause C.l of 
TS 102 471 [1]. 
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The following examples shows how a streamed broadcast TV service should be instantiated. 



<Service serviceID="dvbipdc : //example . com/Channell" > 
<ServiceName>Channell</ServiceName> 

<ServiceType href =' urn: dvb : ipdc : esg: cs : ServiceTypeCS : 1 . 1 ' /> 
<ServiceType href =' urn: dvb : ipdc : esg: cs : ServiceTypeCS : 2 . 1 ' /> 
<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Channell" /> 

</Service> 



5.5 Recommendations on imported datatypes 

The following clause provides recommended restrictions on the use of imported MPEG7 and TV- Anytime datatypes 
within the ESG data model. Where a datatype is not described then the reader should assume that all fields may be used. 

5.5.1 MPEG7 datatypes 

5.5.1 .1 MediaLocatortype 

The MediaLocatorType is used among others in the following datatypes: 

• RelatedMaterialType. 

• ZappingSupportType. 

The StreamID element should not be used. 

The MediaLocatorType allows referring to media objects by using MediaURI. Clause 8.4.3 provides more information 
how to resolve the URI in a case of ESG auxiliary data. 

The MediaLocatorType also enables the embedding of media objects within the ESG itself using the InlineMedia 
datatype. The binary data forming the object may be represented using base64 or hex binary encoding. It is 
recommended that only base64 encoding is used. 

5.5.1 .2 ClassificationSchemeType 

The ClassificationSchemeType is used to enable the definition of classification schemes. This type is used to represent 
the classification schemes defined within the ESG specification. In addition the type may be used within the ESGMain 
fragment to enable the delivery of a classification Scheme. The implementor should be aware of how classification 
schemes are represented using this schema type. For more information on the ClassificationSchemeType and related 
types please refer to ISO/IEC 15938-5 [19]. 

Within a ClassificationScheme it is possible to define the domain for which the scheme is relevant. This feature is not 
used within IPDC. 

5.5.1.3 TextualType 

The TexualType is used to enable the definition of a language specific string. In addition it also allows the signalling of 
a phonetic Alphabet and phoneticTranscription, these attributes should not be used within IPDC. 

5.5.1 .4 TitleMediaType 

The TitleMediaType is used to define non textual titles which can be represented as images, video streams or audio 
streams. Two scheme types are defined to enable their definition: 

• ImageLocatorType (Titlelmage element). 

NOTE 1 : The recommended restrictions defined for the MediaLocatorType also apply for this type. 

• TemporalSegmentLocatorType (Title Video and Title Audio elements). 
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NOTE 2: The TemporalSegmentLocatorType enables the referencing of a Video/audio asset along with an 

(optional) segment to be played from the referenced video asset. Within IPDC we recommend that the 
referencing Video/audio asset is played out in its entirety. Therefore it is recommended to only use the 
elements declared by the MediaLocatorType. 

5.5.1 .5 PersonNameType 

The PersonNameType is used within the CreditsItemType for the definition of actors and characters names. It is 
recommended that at least the GivenName and FamilyName are declared when instantiated. It is recommended not to 
use the dateFrom, dateTo, and type attributes. 

5.5.2 TV-Anytime Datatypes 

A number of TV-Anytime defined schema types are used within the ESG data model. For the syntax and semantics of 
these datatypes the reader should refer to TS 102 822-3-1 [12]. 

5.5.2.1 Classif icationSchemeTableType 

This type may be instantiated as part of the ESGMain fragment, and performs the following roles: 

• Enables the delivery of Classification schemes to the terminal. 

• Enables the declaration of classification scheme aliases. 

The use of classification scheme aliases may be used to minimize the amount of data needed to identify a term. 
However its use is not recommended. 

5.5.2.2 ControlledTermType 

The ControlledTermType is used whenever an element is used to reference a term within a classification Scheme. In 
normal usage only the "href" attribute is required to be instantiated using the following syntax: 

"<schemeName or scheme alias >:<termID>" 

Example: 

urn:dvb:cs: VideoCodecCS:2006: 1 . 1 .2 

The schemeName is the full namespace used to identify the classification scheme that is being used. An alternative is to 
use an alias for the namespace being used. The alias to namespace mapping is declared using the CSAlias element 
within the ClassificationSchemeTableType. 

In the above example the "urn:dvb:cs:VideoCodecCS:2006" is the schemeName and "1.1.2" is the termID being 
referenced within the scheme. 

The schema type also allows the instantiation of the referenced terms name and definition, which may be used if the 
term is not known by terminals. 

5.5.2.3 TVAgentType 

The TVAgentType is used within the CreditsItemType to enable the definition of a person. All fields are valid except 
for the "PersonNamelDRef" and "OrganizationNamelDRef which have no purpose within the ESG data model. 



Example scenarios 



The following examples show how the ESG data model can be used to represent a number of typical business and user 
scenarios. The examples do not imply that this is the only way in which the scenarios can be modelled, but are seen as 
an appropriate way to represent the scenarios. 
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6.1 Traditional TV offering 

6.1.1 Description 

The traditional TV offering scenario is where a broadcast television channel is distributed over the DVB-H network. 
The broadcast channel has a number of events which describe the content that will be broadcast at a particular time. 

The following example shows how this scenario can be modelled where the channel has a single mode of acquisition. 

6.1 .2 ESG data model instantiation 

The service fragment represents the broadcast TV channel, and is used both for attracting the user to tune to the service 
and also provides information to the terminal so that it can consume the service (via the reference to the acquisition 
fragment). The schedule event fragment provides information about what and when content will be available. The 
content fragments describe the content that will be broadcast. 

To create a list of available services the terminal must acquire the service fragments. To tune to the service the terminal 
must acquire the referenced acquisition fragment to obtain the SDP required to configure the player. The SDP may form 
part of the acquisition fragment itself or the acquisition fragment may reference an IP flow on which the SDP can be 
acquired. To find out what is being broadcasted the terminal must acquire the schedule event and content fragments. 

Typically a system will make available information about services and content for a defined period of time into the 
future. This is commonly referred to as schedule depth, with the schedule window being defined as the current time + 
schedule depth. If a service is not available through the current schedule window, then the period for which it is 
available can be inferred from the available schedule event fragments. For example if the service is only available from 
say 6:00 to 10:00 then there will be schedule event fragments available during this time period. It should be noted that 
the optional PublishedEndTime element should be instantiated for the last event to be broadcast before a break in 
transmission. 

NOTE: The published times in the schedule event fragment are for presentational purposes only. There is no 

reference to timestamps which enables the terminal to synchronize the schedule events to the broadcast. 
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Figure 6-1 : TV channel data model 

6. 1 .2.1 Example instantiation 

The following example shows how a traditional broadcast channel delivering a number of content items may be 
described using the ESG data model. 



<ESGMain xmlns="urn:dvb : ipdc :esg: 2005" xmlns :mpeg7="urn:mpeg:mpeg7 : schema: 2 01" 

xmlns : tva="urn: tva : metadata : 2 005" xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" > 
<ESG> 
< Content Table > 

<Content content ID="dvbipdc : //example . com/Contentl" > 
<Title xml : lang="en">Content Item 1</Title> 
<Genre href ="urn: tva rmetadata : cs : ContentCS : 2005 : 1 .4 .5"/> 
<Duration>PT10iy[</Duration> 
</Content> 

<Content contentID="dvbipdc : //example . com/Content3 " > 
<Title xml :lang="en">Content Item 3</Title> 
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<Genre href ="urn: tva rmetadata : cs : ContentCS : 2005 : 1 .4 .5"/> 
<Duration>PT15M</Duration> 

</Content> 

<Content contentID="dvbipdc : //example . com/ContentlOO " > 
<Title xml : lang="en">Content Item 100</Title> 
<Genre href ="urn: tva rmetadata : cs : ContentCS : 2005 : 1 .4 .5"/> 
<Duration>PT5M</Duration> 

</Content> 
</ContentTable> 
<ScheduleEventTable> 

<ScheduleEvent> 

<PublishedStartTime>2006-03-02T20 : 15 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-03-02T21 : 00 : OOZ</PublishedEndTime> 
<ServiceRef lDRef="dvbipdc : //example . com/Channell" /> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/ContentlOO" /> 

</ScheduleEvent> 

<ScheduleEvent> 

<PublishedStartTime>2006-03-02T21 : 00 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-03-02T21 :30 : OOZ</PublishedEndTime> 
<ServiceRef IDRef ="dvbipdc : //example . com/Channell" /> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/Content2 " /> 

</ScheduleEvent> 

<ScheduleEvent> 

<PublishedStartTime>2006-03-02T21 : 30 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-03-02T22 : 00 : OOZ</PublishedEndTime> 
<ServiceRef IDRef ="dvbipdc : //example . com/Channell" /> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/Content 3 " /> 

</ScheduleEvent> 
</ScheduleEventTable> 

<ServiceTable> 

<Service serviceID="dvbipdc : //example . com/Channell" > 
<ServiceName>Channell</ServiceName> 

<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Channell" /> 
</Service> 
</ServiceTable> 



<AcquisitionTable> 

<Acquisition contentMimeType="video/H264 " 

acquisitionID="dvbipdc : //example . com/Acquisition/Channell" ; 
<ComponentDescription> 

<ComponentCharacteristic xsi : type="VideoComponentType" > 
<CodecCharacteristic> 

<Codec href= "urn :dvb:cs:VideoCodecCS: 2006 : 1 . 1 .2"/> 
</CodecCharacteristic> 
<FrameRate>2 5</FrameRate> 
</ComponentCharacteristic> 
<ComponentCharacteristic xsi : type="AudioComponentType" > 

<Codec href=" urnrdvb : cs : AudioCodecCS : 2 006 : 1 . 3 . 2 "/> 
<Language >en< /Language > 
</ComponentCharacteristic> 

<SessionDescription xsi : type="SDPRef Type" > 
<SDPStream> 

<! [CDATA[v=0 
o=example . com 751092616 751111042 IN IP6 FE80::1:4D3E 
s=SDP Delivery 
t = 

a=flute-tsi:9532 
a=f lute-ch: 1 

a=source-f liter: incl IN IP6 * FE80 : : 2 : : 70CA 
m=application 12345 FLUTE/UDP 
C=IN IP6 FF15 : :1:141B 
]]> 

</SDPStream> 

<SDPURI>http: //example. com/defaultSDP</SDPURI> 
</SessionDescription> 
</ComponentDescription> 
</Acquisition> 
</AcquisitionTable> 
</ESG> 
</ESGMain> 
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6.2 Soap opera service 

6.2.1 Description 

The soap opera service scenario builds upon the traditional TV offering scenario, by instantiating a service which 
describes a subset of events available on the other service. For example if we have a broadcast TV service which 
transmits a mixture of content types. The operator may wish to provide access to a subset of the content available on the 
broadcast TV channel e.g. soap operas. 

6.2.2 ESG data model instantiation 

This scenario adds in addition to those of a traditional TV service, a further service fragment which is used to describe 
the soap opera service. This service fragment may reference the same acquisition fragment as that of the broadcast TV 
service. A number of schedule event fragments forming the soap opera service are instantiated but reference the same 
content descriptions as those of the broadcast TV service. 

Access to the soap opera service is the same as if it were a broadcast TV channel. 



Service Fragment (Channel 1) 












i 


i 




i 


i 




a 






ScheduleEvent 
Fragment 




ScheduleEvent 
Fragment 




ScheduleEvent 






} 


r 










t 




V 


Content Fragment 




Content Fragment 




Content Fragment 




Acquisition 
Fragment 


n 








7 




i 


i 


ScheduleEvent 
Fragment 




ScheduleEvent 
Fragment 






} 


r 


1 






Service Fragment (Soap Opera) 













Figure 6-2: Soap opera data model 



6.2.2.1 Example instantiation 



<ESGMain xmlns="urn:dvb : ipdc :esg: 2 005" xmlns :mpeg7="urn:mpeg:mpeg7 : schema: 2 01" 

xmlns : tva="urn: tva : metadata : 2 005" xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" 
> 
<ESG> 
<ContentTable> 

<Content content ID="dvbipdc : //example . com/Contentl" > 
<Title xml : lang="en">Content Item 1</Title> 
<Genre href ="urn: tva rmetadata : cs : ContentCS : 2005 : 1 .4 .5"/> 
<Duration>PT3 0M</Duration> 
</Content> 

<Content contentID="dvbipdc : //example . com/SoapOperal" > 
<Title xml :lang="en">Soap Opera 1</Title> 
<Genre href = "urn: tva rmetadata : cs : ContentCS : 2 005 : 1 . 6"/> 
<Duration>PT3 0M</Duration> 
</Content> 

<Content content ID="dvbipdc : //example . com/ContentlOO" > 
<Title xml :lang="en">Content Item 100</Title> 
<Genre href = "urn: tva rmetadata : cs : ContentCS : 2 005 : 1 .4 .5"/> 
<Duration>PT45M</Duration> 
</Content> 
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<Content content ID="dvbipdc : //example . com/SoapOpera2 " > 
<Title xml : lang="en">Soap Opera 2</Title> 
<Genre href =" urn: tva : metadata : cs : Content CS :2005:1.6"/> 
<Duration>PT3 0M</Duration> 

</Content> 
</ContentTable> 

<!-- ScheduleEvents for the real TV Channel --> 
<ScheduleEventTable> 

<ScheduleEvent> 

<PublishedStartTime>2006-03-02T20 : 15 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-03-02T21 : 00 : OOZ</PublishedEndTime> 
<ServiceRef IDRef="dvbipdc : //example . com/Channel 1" /> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/ContentlOO" /> 

</ScheduleEvent> 

<ScheduleEvent> 

<PublishedStartTime>2006-03-02T21 : 00 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-03-02T21 : 30 : OOZ</PublishedEndTime> 
<ServiceRef IDRef ="dvbipdc : //example . com/Channell" /> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/SoapOperal" /> 

</ScheduleEvent> 

<ScheduleEvent> 

<PublishedStartTime>2006-03-02T21 :30 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-03-02T22 : 00 : OOZ</PublishedEndTime> 
<ServiceRef IDRef ="dvbipdc : //example . com/Channell" /> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/Content 1" /> 

</ScheduleEvent> 

<ScheduleEvent> 

<PublishedStartTime>2006-03-03T22 : 15 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-03-02T22 : 45 : OOZ</PublishedEndTime> 
<ServiceRef IDRef ="dvbipdc : //example . com/Channell" /> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/SoapOpera2 " /> 

</ScheduleEvent> 
<!-- Schedule Events for the Virtual Soap Opera Service --> 

<ScheduleEvent> 

<PublishedStartTime>2006-03-02T21 : 00 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-03-02T21 : 30 : OOZ</PublishedEndTime> 
<ServiceRef IDRef ="dvbipdc : //example . com/SoapOpera" /> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/SoapOperal" /> 

</ScheduleEvent> 

<ScheduleEvent> 

<PublishedStartTime>2006-03-03T22 : 15 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-03-02T22 : 45 : OOZ</PublishedEndTime> 
<ServiceRef IDRef ="dvbipdc : //example . com/SoapOpera" /> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/SoapOpera2 " /> 

</ScheduleEvent> 
</ScheduleEventTable> 

<ServiceTable> 
<!-- Real Service Information --> 

<Service serviceID="dvbipdc : //example . com/Channell" > 
<ServiceName>Channell</ServiceName> 

<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Channell" /> 
</Service> 
<!-- Virtual Soap Opera Service --> 

<Service serviceID="dvbipdc : //example . com/SoapOpera" > 
<ServiceName>Soap Opera</ServiceName> 

<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Channell" /> 
</Service> 
</ServiceTable> 

<AcquisitionTable> 

<Acquisition contentMimeType="video/H2 64 " 

acquisitionID="dvbipdc : //example . com/Acquisition/Channell" > 
<ComponentDescription> 

<ComponentCharacteristic xsi : type="VideoComponentType" > 
<CodecCharacteristic> 

<Codec href=" urnrdvb : cs : VideoCodecCS : 2006 : 1 . 1 . 2 /> 
</CodecCharacteristic> 
<FrameRate>2 5</FrameRate> 
</ComponentCharacteristic> 

<Component Characteristic xsi : type="AudioComponentType" > 
<Codec href="urn:dvb:cs:AudioCodecCS:2 006 : 1 .3 .2"/> 
<Language >en< /Language > 
</ComponentCharacteristic> 

<SessionDescription xsi : type="SDPRef Type" > 
<SDPStream> 

< ! [CDATA[v=0 



ETSI 



25 ETSI TS 1 02 592 V1 .1 .1 (2007-1 0) 



o=example . com 751092616 751111042 IN IP6 FE80::1:4D3E 

s=SDP Delivery 

t = 

a=flute-tsi : 9532 

a=f lute-ch: 1 

a=source-filter: incl IN IP6 * FE80 : : 2 : : 70CA 

m=application 12345 FLUTE/UDP 

C=IN IP6 FF15: :1:141B 

]]> 

</SDPStream> 

<SDPURI>http: //example. com/defaultSDP</SDPURI> 
</SessionDescription> 
</ComponentDescription> 
</ Acquis! tion> 
</AcquisitionTable> 
</ESG> 
</ESGMain> 



6.3 TV service with captions 

6.3.1 Description 

Captions are subtitles that are rendered in the video for visuaHsation. Two types of captions are distinguished: Closed 
captions and open captions. 

Closed captions are subtitles that are provided in a separate transport flow to that of the video. The rendering of the 
captions is performed at the time of presentation, if requested by the user. 

Open captions are subtitles that are burnt into the video that is delivered, and so are always presented to the user. 

6.3.2 ESG datamodel instantiation of closed captions 

This use case shows how closed captions are signalled within the ESG. Closed captions are announced using the 
CaptionLanguage element within the content fragment that represents the content that is to be delivered. 

NOTE: The implementor should be aware that the mechanism used for signalling closed captions may change in 
a later version of the ESG specification. In this version unlike other component types the availability of 
closed captions is not signalled within the acquisition fragment. 

Details about the format and delivery of the closed captions is provided by the SDP. The SDP to be used for the 
consumption of the content containing closed captions is signalled by the \cquisition fragment associated with the 
content within a schedule event. 

6.3.2.1 Example instantiation 



<ESGMain xmlns="urn:dvb : ipdc : esg: 2 005" xmlns :mpeg7="urn:mpeg:mpeg7 : schema : 2 001" 

xmlns : tva="urn: tva : metadata : 2 05" xmlns :xsi="http: //www. w3 . org/2 001/XMLSchema- instance" 
> 
<ESG> 
< Content Table > 

<Content contentID="dvbipdc : //example . com/Contentl" > 
<Title xml :lang="en">Content Item 1</Title> 
<Genre href ="urn: tva rmetadata : cs : ContentCS : 2005 : 1 .4 .5"/> 
<CaptionLanguage closed="true" >en</CaptionLanguage> 
<Duration>PT3 0M</Duration> 
</Content> 
</ContentTable> 

<ScheduleEvent Table > 
<ScheduleEvent> 

<PublishedStartTime>2006-03-02T20 : 15 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-03-02T21 : 00 : OOZ</PublishedEndTime> 
<ServiceRef IDRef="dvbipdc : //example . com/Channell" /> 
<ContentFragmentRef IDRef="dvbipdc : //example . com/Contentl" /> 
<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/ClosedCaption" > 

<Label>ClosedCaption< /Label > 
</AcquisitionRef > 
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</ScheduleEvent> 
</ScheduleEventTable> 

<ServiceTable> 

<Service serviceID="dvbipdc : //example . com/Channell" > 
<ServiceName>Channell</ServiceName> 

<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Channell" /> 
</Service> 
</ServiceTable> 

< Acquis! tionTable> 

<Acquisition contentMimeType="video/H2 64 " 

acquisitionID="dvbipdc : //example . com/Acquisition/Channell" > 
<ComponentDescription> 

<ComponentCharacteristic xsi : type="VideoComponentType" > 
<CodecCharacteristic> 

<Codec href=" urnrdvb : cs : VideoCodecCS : 2 006 : 1 . 1 . 2 "/> 
</CodecCharacteristic> 
<FrameRate>2 5</FrameRate> 
</ComponentCharacteristic> 

<Component Characteristic xsi : type="AudioComponentType" > 
<Codec href="urn:dvb:cs:AudioCodecCS:2 006 : 1 .3 .2"/> 
<Language >en< /Language > 
</ComponentCharacteristic> 

<SessionDescription xsi : type="SDPRef Type" > 
<SDPStream> 

< ! [CDATA[v=0 
o=example . com 751092616 751111042 IN IP6 FE80::1:4D3E 
s=SDP Delivery 
t = 

a=flute-tsi:9532 
a=f lute-ch: 1 

a=source-f liter: incl IN 1P6 * FE80 : : 2 : : 70CA 
m=application 12345 FLUTE/UDP 
C=1N 1P6 FF15 : :1:141B 
]]> 

</SDPStream> 

<SDPURl>http: //example. com/defaultSDP</SDPURl> 
</SessionDescription> 
</ComponentDescription> 
</Acquisition> 
<Acquisition contentMimeType="video/H2 64 " 

acquisitionlD="dvbipdc : //example . com/Acquisition/ClosedCaption" > 
<ComponentDescription> 

<ComponentCharacteristic xsi : type="VideoComponentType" > 
<CodecCharacteristic> 

<Codec href= "urn :dvb:cs: VideoCodecCS: 2 006 : 1 . 1 .2"/> 
</CodecCharacteristic> 
<FrameRate>2 5</FrameRate> 
</ComponentCharacteristic> 

<Component Characteristic xsi : type="AudioComponentType" > 
<Codec href="urn:dvb:cs:AudioCodecCS:2 006 : 1 .3 .2"/> 
<Language >en< /Language > 
</ComponentCharacteristic> 

<SessionDescription xsi : type="SDPRef Type" > 
<SDPStream> 

<! [CDATA[v=0 
o=example . com 751092616 751111042 IN 1P6 FE80::1:4D3E 
s=SDP Delivery 
t = 

a=flute-tsi : 9532 
a=f lute-ch: 1 

a=source-filter: incl IN 1P6 * FE80 : : 2 : : 70CA 
m=application 12345 FLUTE/UDP 
C=IN 1P6 FF15: :1:141B 
]]> 

</SDPStream> 
<SDPURl>http: //example. com/ClosedCaptionSDP</SDPURl> 
</SessionDescription> 
</ComponentDescription> 
</Acquisition> 

</AcquisitionTable> 
</ESG> 
</ESGMain> 
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6.3.3 ESG datamodel instantiation of open captions 

This use case shows how open captions may be signalled within a ESG instance. Open captions may be signalled both 
within the content fragment and may also be signalled within the video ComponentCharateristics element of the 
acquisition fragment associated with the schedule event delivering the content. If open captions are signalled within the 
content fragment it is for user information. There should be only one CaptionLanguage element instantiated, since it is 
not possible to have multiple open captions within a single content item. The open captions within the acquisition 
fragment signals the terminal the availability of open captions in a particular video stream. 

Unlike closed captions the SDP used for the consumption of a content item is the same as a content item without open 
captions provided the components and their encoding parameters are the same. 

6.3.3.1 Example instantiation 



<ESGMain xmlns="urn:dvb : ipdc : esg: 2005" xmlns :mpeg7="urn:mpeg:mpeg7 : schema : 2 001" 

xmlns : tva="urn: tva : metadata : 2 05" xmlns :xsi="http: //www. w3 . org/2 00 1/XMLSchema- instance" 
> 
<ESG> 
<ContentTable> 

<Content contentlD="dvbipdc : //example . com/Contentl" > 
<Title xml :lang="en">Content Item 1</Title> 
<Genre href ="urn: tva rmetadata : cs : ContentCS : 2005 : 1 .4 .5"/> 
<CaptionLanguage closed=" false" >en</CaptionLanguage> 
<Duration>PT3 0M</Duration> 
</Content> 
</ContentTable> 

<ScheduleEventTable> 
<ScheduleEvent> 

<PublishedStartTime>2006-03-02T20 : 15 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-03-02T21 : 00 : OOZ</PublishedEndTime> 
<ServiceRef IDRef="dvbipdc : //example . com/Channell" /> 
<ContentFragmentRef IDRef="dvbipdc : //example . com/Contentl" /> 
<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/OpenCaptions" > 

<Label>OpenCaption< /Label > 
< /Acquis! tionRef> 
</ScheduleEvent> 
</ScheduleEventTable> 

<ServiceTable> 

<Service serviceID="dvbipdc : //example . com/Channell" > 
<ServiceName>Channell</ServiceName> 

<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Channell" /> 
</Service> 
</ServiceTable> 

<AcquisitionTable> 

<Acquisition contentMimeType="video/H2 64 " 

acquisitionID="dvbipdc : //example . com/Acquisition/Channell" > 
<ComponentDescription> 

<ComponentCharacteristic xsi : type="VideoComponentType" > 
<CodecCharacteristic> 

<Codec href="urn:dvb:cs:VideoCodecCS:2 006 : 1 . 1 .2"/> 
</CodecCharacteristic> 
<FrameRate>2 5</FrameRate> 
</ComponentCharacteristic> 

<Component Characteristic xsi : type="AudioComponentType" > 
<Codec href="urn:dvb:cs:AudioCodecCS:2 006 : 1 .3 .2"/> 
<Language >en< /Language > 
</ComponentCharacteristic> 

<SessionDescription xsi : type="SDPRef Type" > 
<SDPStream> 

<! [CDATA[v=0 
o=example . com 751092616 751111042 IN IP6 FE80::1:4D3E 
s=SDP Delivery 
t = 

a=f lute-tsi : 9532 
a=f lute-ch: 1 

a=source-filter: incl IN IP6 * FE80 : : 2 : : 70CA 
m=application 12345 FLUTE/UDP 
C=IN IP6 FF15: :1:141B 
]]> 

</SDPStream> 
<SDPURI>http: //example. com/defaultSDP</SDPURI> 
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</SessionDescription> 
</ComponentDescription> 
< /Acquis! tion> 
<Acquisition contentMimeType="video/H264 " 

acquisitionID="dvbipdc : //example . com/Acquisition/OpenCaption" 
<ComponentDescription> 

<Component Characteristic xsi : type="VideoComponentType" > 
<CodecCharacteristic> 

<Codec href="urn:dvb:cs:VideoCodecCS:2 006 : 1 . 1 .2"/> 
</CodecCharacteristic> 
<FrameRate>2 5</FrameRate> 

<OpenCaptionLanguage>en</OpenCaptionLanguage> 
</ComponentCharacteristic> 

<ComponentCharacteristic xsi : type="AudioComponentType" > 
<Codec href="urn:dvb:cs:AudioCodecCS:2 006 : 1 .3 .2"/> 
<Language >en< /Language > 
</ComponentCharacteristic> 

<SessionDescription xsi : type="SDPRef Type" > 
<SDPStream> 

<! [CDATA[v=0 
o=example . com 751092616 751111042 IN IP6 FE80::1:4D3E 
s=SDP Delivery 
t = 

a=flute-tsi : 9532 
a=f lute-ch: 1 

a=source-filter: incl IN IP6 * FE80 : : 2 : : 70CA 
m=application 12345 FLUTE/UDP 
C=IN IP6 FF15: :1:141B 
]]> 

</SDPStream> 
<SDPURI>http: //example. com/defaultSDP</SDPURI> 
</SessionDescription> 
</ComponentDescription> 
</Acquisition> 
</AcquisitionTable> 
</ESG> 
</ESGMain> 



6.4 TV service with additional options 
6.4.1 Description 

The scenario TV Service with additional options' is an extension of the traditional TV offering, in that one or more 
events may have additional options available. In this clause two examples are discussed: 

• A broadcast service may have by default an English audio component for all scheduled events available on the 
service. However for particular schedule events an additional French audio track is made available. For the 
schedule event with the French audio track, the user is able to select the audio language that the player will 
use. 

• A broadcast service may have by default a particular video stream available. In the case of multiple video TV 
services particular schedule events may have one or more additional optional video components available. For 
example a broadcast service may have by default a main camera angle video stream for all schedule events 
available on the service. However for particular schedule events additional video streams of other camera 
angles are made available. For such a schedule event the user is able to select the camera angle that the media 
player will use. 

The ESG data model supports two approaches for signalling these options: 

• The acquisition fragment referenced from the service or schedule fragment refers to an SDP file which signals 
the different optional IP flows. 

• Multiple acquisition fragments referenced from a service or schedule fragment, where each describes a 
different option. 

The first approach allows the application initialized by the SDP file to switch between the different options while the 
latter approach enables the user to select an option based on the ESG information. However in this case the application 
consuming the service may not have access to the ESG information. 
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Where SDP files are delivered using a separate fransport flow to that of the ESG, it is possible to signal SDP changes to 
the terminal using the dynamic SDP option as described in TS 102 591 [39]. 

Based on this observation it is recommended to signal options in the SDP file if possible. An example of such options is 
the support of multiple languages. If the options can not be described in the SDP file it is recommended to signal them 
in separate acquisition fragments. An example for this latter case is the description of a multiple video TV service. 

When multiple acquisition fragments are instantiated it is recommended that the "Label" element within the 
AcquisitionFragmentRef element is used to give an indication of the intent for the referenced acquisition. As an 
example, if a scheduled event has additional audio tracks to that of the default acquisition, then the label could be set to 
"alternate audio". This could then be used by the terminal to provide a hint to the user what additional options the 
acquisition fragment gives. It should be noted that the "label" element is free text and so the terminal should not infer 
any behaviour from its value. 

In addition to the "label" element in the AcqusitionFragmentRef we have the "purpose" attribute within the 
ComponentCharacteristicsType. This "purpose" attribute may be use to signal the purpose of the component, and may 
be presented to the user to enable the selection of a component when there are multiple options. As an example an 
acquisition fragment may signal that there is an original audio component and a dubbed audio component, the "purpose" 
could then be used to provide a prompt to the user to make a selection. 

NOTE: This inhomogeneous approach of signalling options have been identified in the standardisation work for 
IPDC. Work is continued to resolve the signalling of options in a future version of IPDC. 

6.4.2 ESG data model instantiation of the multi lingual TV service 

The instantiation of this scenario is the same as the traditional TV offering service except that the schedule event 
fragment which represents the broadcast content that has the additional audio component has a reference to an 
acquisition fragment which announces the availability of the French audio component. The additional acquisition 
fragment also either: 

• Contains an SDP description announcing the French component, along with its IP flow. 

• A reference to the IP flow carrying the SDP for the service, and the Content-Location value used within the 
FDT to identify the SDP object to be acquired from the FLUTE carousel. 

Once the terminal has acquired the SDP, the terminal selects the appropriate audio language component based on the 
SDP a=lang:<language tag> field for the audio component. 

NOTE: In TS 102 591 [39] it is described that languages are represented in SDP according to the rules defined in 
RFC 2327 [17]. It is recommended that the values of the "language" element follow the same rules so that 
language signalling remains consistent across SDP and ESG. 

Once the broadcast of the event has finished it is the responsibility of the terminal to determine if it needs to retune to 
another audio component (if the currently selected component is no longer available). This can be determined by 
querying the schedule event fragments, or by the non receipt of IP packets for the selected audio component. In which 
case the system should retune to the default audio component. 
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Figure 6-3: Multi lingual ESG data model 
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6.4.2.1 Example instantiation 



The following example shows how the ESG data model may be used to signal the availability of an additional French 
audio track during the broadcasting of a single content item. This is done by instantiating an acquisition fragment that 
describes all components available during the schedule event that announces the availability of the content. For all other 
content items the acquisition fragment referenced by the service fragment provides a description of the components 
forming the service. 



<ESGMain xmlns="urn:dvb : ipdc :esg: 2005" xmlns :mpeg7="urn:mpeg:mpeg7 : schema: 2 01" 

xmlns : tva="urn: tva : metadata : 2 005" xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" 
> 
<ESG> 
<ContentTable> 

<Content contentlD="dvbipdc : //example . com/Contentl" > 
<Title xml :lang="en">Content Item 1</Title> 
<Genre href = "urn: tva : metadata : cs : ContentCS : 2005 : 1 . 4 . 5"/> 
<Duration>PT3 0M</Duration> 
</Content> 

<Content content ID="dvbipdc : //example . com/Content21" > 
<Title xml :lang="en">Content 21</Title> 
<Genre href = "urn: tva : metadata : cs : ContentCS : 2 005 : 1 . 6"/> 
<Duration>PT3 0M</Duration> 
</Content> 

<Content contentID="dvbipdc : //example . com/ContentlOO" > 
<Title xml : lang="en">Content Item 100</Title> 
<Genre href ="urn: tva :metadata : cs : ContentCS : 2005 : 1 .4 .5"/> 
<Duration>PT4 5M</Duration> 
</Content> 
</Content Table > 

<ScheduleEventTable> 
<ScheduleEvent> 

<PublishedStartTime>2006-03-02T20 : 15 : OOZ</PublishedStartTime> 

<PublishedEndTime>2006-03-02T21 : 00 : OOZ</PublishedEndTime> 

<ServiceRef IDRef="dvbipdc : //example . com/Channell" /> 

<ContentFragmentRef IDRef ="dvbipdc : //example . com/ContentlOO" /> 
</ScheduleEvent> 
<ScheduleEvent> 

<PublishedStartTime>2006-03-02T21 : 00 : OOZ</PublishedStartTime> 

<PublishedEndTime>2006-03-02T21 :30 : OOZ</PublishedEndTime> 

<ServiceRef IDRef ="dvbipdc : //example . com/Channell" /> 

<ContentFragmentRef IDRef ="dvbipdc : //example . com/Content21" /> 

<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/MultiLingualevent " > 
<Label>Multiple Audio</Label> 

< /Acquis! tionRef> 
</ScheduleEvent> 
<ScheduleEvent> 

<PublishedStartTime>2006-03-02T21 : 30 : OOZ</PublishedStartTime> 

<PublishedEndTime>2006-03-02T22 : 00 : OOZ</PublishedEndTime> 

<ServiceRef IDRef ="dvbipdc : //example . com/Channell" /> 

<ContentFragmentRef IDRef ="dvbipdc : //example . com/Contentl" /> 
</ScheduleEvent> 
</ScheduleEventTable> 

<ServiceTable> 

<Service serviceID="dvbipdc : //example . com/Channell" > 
<ServiceName>Channell</ServiceName> 

<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Channell" /> 
</Service> 
</ServiceTable> 

<AcquisitionTable> 

<!-- Generic Acquisition fragment containing the default Audio track --> 
<Acquisition contentMimeType="video/H2 64 " 

acquisitionID="dvbipdc : //example . com/Acquisition/Channell" > 
<ComponentDescription> 

<ComponentCharacteristic xsi : type="VideoComponentType" > 
<CodecCharacteristic> 

<Codec href="urn:dvb:cs:VideoCodecCS:2 006 : 1 . 1 .2"/> 
</CodecCharacteristic> 
<FrameRate>2 5</FrameRate> 
</ComponentCharacteristic> 

<Component Characteristic xsi : type="AudioComponentType" > 
<Codec href="urn:dvb:cs:AudioCodecCS:2 006 : 1 .3 .2"/> 
<Language >en< /Language > 
</ComponentCharacteristic> 
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<SessionDescription xsi : type="SDPRefType" > 
<SDPStream> 

<! [CDATA[v=0 
o=example . com 751092616 751111042 IN IP4 10.45.2.30 
s=SDP Delivery for Channell 
t = 

a=f lute-ch: 1 

m=application 12345 FLUTE/UDP 
C=IN IP4 239.255.255.102/127 
a=flute-tsi: 98765432 
]]> 

</SDPStream> 
<SDPURI>http: //example. com/defaultSDP</SDPURI> 
</SessionDescription> 
</ComponentDescription> 
< /Acquis! tion> 

<Acquisition contentMimeType= "video/H264 " 

acquisitionID="dvbipdc : //example . com/Acquisition/MultiLingualevent " 
<ComponentDescription> 

<Component Characteristic xsi : type="VideoComponentType" > 
<CodecCharacteristic> 

<Codec href="urn:dvb:cs:VideoCodecCS:2 006 : 1 . 1 .2"/> 
</CodecCharacteristic> 
<FrameRate>2 5</FrameRate> 
</ComponentCharacteristic> 

<ComponentCharacteristic xsi : type="AudioComponentType" > 
<Codec href="urn:dvb:cs:AudioCodecCS:2 006 : 1 .3 .2"/> 
<Language >en< /Language > 
</ComponentCharacteristic> 

<ComponentCharacteristic xsi : type="AudioComponentType" > 
<Codec href="urn:dvb:cs:AudioCodecCS:2 006 : 1 .3 .2"/> 
<Language>f r< /Language > 
</ComponentCharacteristic> 

<SessionDescription xsi : type="SDPRef Type" > 
<SDPStream> 

<! [CDATA[v=0 
o=example . com 751092616 751111042 IN IP6 FE80::1:4D3E 
s=SDP Delivery 
t = 

a=f lute-tsi : 9532 
a=f lute-ch: 1 

a=source-filter: incl IN IP6 * FE80 : : 2 : : 70CA 
m=application 12345 FLUTE/UDP 
C=IN IP6 FF15: :1:141B 
]]> 

</SDPStream> 
<SDPURI>http: //example. com/mult iAudioSDP</SDPURI> 
</SessionDescription> 
</ComponentDescription> 
</Acquisition> 
</AcquisitionTable> 
</ESG> 
</ESGMain> 



6.4.3 ESG data model instantiation of the multiple video TV service 

The instantiation of this scenario is the same as the traditional TV offering service except that the schedule event 
fragment which represents the broadcast content that has the additional video streams has a reference to an acquisition 
fragment(s) which announce the availability of the additional video stream(s). The additional acquisition fragment(s) 
also either: 

• contains an SDP description announcing one of the video streams, along with its IP flow; or 



• 



a reference to the IP flow carrying the SDP for the service, and the Content-Location value used within the 
FDT to identify the SDP object to be acquired from the FLUTE carousel. 



This mechanism allows one-to-one mapping between acquisition fragment and corresponding SDP file for each 
selectable option. 
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The option described in Service-related acquisition fragment has to be duplicated as an option in Schedule-related 
acquisition fragments, see clause 5.10.1 in TS 102 471 [1]. Anyhow, Schedule-related acquisition fragments and 
associated SDP files are representing alternatives to other Schedule-related acquisition fragments and their SDP files, 
respectively. 

Once the broadcast of the event has finished it is the responsibility of the terminal to determine if it needs to retune to 
another video stream (if the currently selected stream is no longer available). This can be determined by querying the 
schedule event fragments, or by the non receipt of IP packets for the selected video stream. In which case the system 
should retune to the default video stream described in the Service-related acquisition fragment. 
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Figure 6-4: Multi video ESG data model (generic) 
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Figure 6-5: Multi video ESG data model (optimized for transport) 



6.4.3.1 Example instantiation 

The following is an example instantiation of a multiple video TV service as described in figure 6-5. In this example the 
ScheduleEvent describing a sport event has labelled references to two acquisition fragments describing two different 
camera angles. 



<ESGMain xmlns="urn:dvb : ipdc : esg: 2 05" xmlns : tva="urn: tva : metadata : 2005" 

xmlns :mpeg7="urn:mpeg:mpeg7 : schema: 2 01" xmlns :xsi="http: //www. w3 . org/2 1/XMLSchema" 
<ESG> 

<ServiceTable> 

< Service clearToAir="l" servicelD="dvbipdc : //example . com/1018 "> 
<ServiceName xml : lang="en" >Channel 2</ServiceName> 
<AcquisitionRef IDRef ="dvbipdc : //example . com/2865"/> 
</Service> 
</ServiceTable> 

<ScheduleEventTable> 

< ScheduleEvent clearToAir="l" scheduleID="dvbipdc : //example . com/2 7 06" > 
<PublishedStartTime>2006-09-20T06 : 00 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-09-20T07 : 00 : OOZ</PublishedEndTime> 
<ServiceRef IDRef ="dvbipdc : //example . com/1018 " /> 
< Content Fragment Ref IDRef ="dvbipdc : //example . com/2 707 "/> 
< /ScheduleEvent > 
< ScheduleEvent clearToAir="l" scheduleID="dvbipdc : //example . com/2 8 06" > 
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<PublishedStartTime>2006-09-20T16 : 00 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-09-20T17 : 30 : OOZ</PublishedEndTime> 
<ServiceRef IDRef ="dvbipdc : //example . com/1018 "/> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/2 807 "/> 
<AcquisitionRef IDRef ="dvbipdc : //example . com/2865 " > 

<Label>Primary Camera Angle</Label> 
</AcquisitionRef > 
<AcquisitionRef IDRef ="dvbipdc : //example . com/2875" > 

<Label>Alternative Camera Angle</Label> 
</AcquisitionRef > 
</ScheduleEvent> 

<ScheduleEvent clearToAir="l" scheduleID="dvbipdc : //example . com/2 906" > 
<PublishedStartTime>2006-09-20T20 : 00 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-09-20T22 : 00 : OOZ</PublishedEndTime> 
<ServiceRef IDRef ="dvbipdc : //example . com/1018 "/> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/2907"/> 
</ScheduleEvent> 
</ScheduleEventTable> 

< Content Table > 

<Content content ID="dvbipdc : //example . com/2707" > 

<Title xml : lang=" en" > Example Content 1</Title> 

<ServiceRef IDRef ="dvbipdc : //example . com/1018"/> 

<Duration>P0Y0M0DT01H0 0M0 0S</Duration> 
</Content> 
<Content contentID="dvbipdc : //example . com/2807" > 

<Title xml : lang="en" >Example Content 2</Title> 

<ServiceRef IDRef ="dvbipdc : //example . com/1018"/> 

<Duration>P0Y0M0DT01H3 0M0 0S</Duration> 
</Content> 
<Content contentID="dvbipdc : //example . com/2907" > 

<Title xml : lang="en">Example Content 3</Title> 

<ServiceRef IDRef ="dvbipdc : //example . com/1018"/> 

<Duration>P0Y0M0DT02H0 0M0 0S</Duration> 
</Content> 
</ Content Table > 

<AcquisitionTable> 

<Acquisition acquisitionID="dvbipdc : //example . com/2865" contentMimeType="video/h264 " > 
<ComponentDescription> 

<ComponentCharacteristic purpose=" Primary Camera Angle" xsi : type="VideoComponentType" > 

<Bandwidth>128000</Bandwidth> 
</ComponentCharacteristic> 

<Component Characteristic xsi : type="AudioComponentType" > 
<Bandwidth>32 0</Bandwidth> 
<Language >eng< /Language > 
</ComponentCharacteristic> 
<SessionDescription> 
<SDPStream/> 

<SDPURI>dvbipdc : //example . com/2 866 . SDP</SDPURI> 
</SessionDescription> 
</ComponentDescription> 
</Acquisition> 

<Acquisition acquisitionID="dvbipdc : //example . com/2875 " contentMimeType="video/h264 " > 
<ComponentDescription> 

<ComponentCharacteristic purpose= "Alternative Camera Angle" xsi : type="VideoComponentType" > 

<Bandwidth>12 8000</Bandwidth> 
</ComponentCharacteristic> 

<Component Characteristic xsi : type="AudioComponentType" > 
<Bandwidth>32 0</Bandwidth> 
<Language >en< /Language > 
</ComponentCharacteristic> 
<SessionDescription> 
<SDPStream/> 

<SDPURI>dvbipdc : //example . com/2876 . SDP</SDPURI> 
</SessionDescription> 
</ComponentDescription> 
</Acquisition> 
</AcquisitionTable> 

</ESG> 
</ESGMain> 
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6.5 



File download service 



6.5.1 Description 

The File download service scenario shows how the ESG data model can be used to describe the delivery of files 
e.g. HTML pages, AV Files, ring tones, using a FLUTE carousel. The example given, shows how to describe the 
delivery of a number of content items using FLUTE during a well defined time period. During this time period the 
described items are repeatedly transmitted for acquisition by the receiving terminal. The SDP for the FLUTE carousel 
session is carried within the ESG data, as it is static in nature. 

6.5.2 ESG data model instantiation 

The example describes 3 content items within the "ContentTable" element that are to be made available over the 
FLUTE carousel. 

The single "ScheduleEvent" entry within the "ScheduleEventTable" describes the content items available during the 
schedule event fragment's time period (This could be the total lifetime of the FLUTE session OR it could just be the 
time period at which these content items are available within the FLUTE session. At other times the session may be 
used to carrying other content items.) The ContentFragmentRef and ContentLocation pairs specify the appropriate 
object (ContentLocation) that should be acquired from the FLUTE session for the required content item 
(ContentFragmentRef) . 

The "Service" entry within the "ServiceTable" describes the actual download service, and is used to attract the user to 
consume the service. The service entry contains a reference (AcquisitionRef) to an acquisition fragment which provides 
details about where the service can be found and the components forming the service. 

The "acquisition" entry within the "AcquisitionTable" contains information about the file download component along 
with the SDP required to enable the terminals receiving application to consume the service. 

When the user wishes to acquire one of the content items carried within the FLUTE carousel, the terminal should tune 
to the FLUTE carousel at the appropriate time (announced by the PublishedStartTime and PublishedEndTime within the 
schedule event fragment). The terminal might join the FLUTE session in between PublishedStartTime and 
PublishedEndTime and still receive the files due to transport of files in multiple cycles or due to requesting missing 
packets using the file repair mechanism. To join the session the terminal reads the SDP that describes the FLUTE 
session (announced by the SDP element). The terminal then acquires the FDT for the FLUTE session and locates a file 
entry with a "Content-Location" attribute equal to the "ContentLocation" element for the content item the user wishes to 
acquire. Once this has been found the corresponding "TOI" entry identifies the ALC Object that should be acquired 
from the carousel. 
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Figure 6-6: File download data model 
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6.5.2.1 Example instantiation 



The following example shows how a number of ring tones that are to be delivered within a single FLUTE session are 
announced to the terminal. These ring tones are only available during a specific time period. This is announced using a 
schedule event fragment. In this example for each ring tone a ContentFragmentRef element is instantiated within the 
schedule event fragment which references a content fragment that describes the ring tone. In addition for each ring tone 
a ContentLocation element is instantiated. This informs the terminal the file within the FLUTE session that should be 
acquired when a user selects a particular ring tone. 



<ESGMain xmlns="urn:dvb : ipdc : esg: 2 005" xmlns :mpeg7="urn:mpeg:mpeg7 : schema : 2 001" 

xmlns : tva="urn: tva : metadata : 2 05" xmlns :xsi = "http: //www. w3 . org/2 00 1/XMLSchema- instance" 
> 
<ESG> 

<ContentTable> 

<Content contentlD="dvbipdc : //example . com/RingTonel" > 
<Title xml :lang="en">Ring Tone 1</Title> 

<Genre href =" urn: tva : metadata : cs : Content CS :2005:5.4.5"/> 
<Duration>PT2 0S</Duration> 
</Content> 

<Content contentID="dvbipdc : //example . com/RingTone2 " > 
<Title xml :lang="en">Ring Tone 2</Title> 
<Genre href =" urn: tva : metadata : cs : Content CS :2005:5.6"/> 
<Duration>PT3 0S</Duration> 
</Content> 

<Content contentID="dvbipdc : //example . com/RingTonelOO" > 
<Title xml : lang="en">Ring Tone 100</Title> 
<Genre href = "urn: tva : metadata : cs :ContentCS :20 05:5.4.5"/> 
<Duration>PT3 0S</Duration> 
</Content> 
</ContentTable> 
<ScheduleEventTable> 
<ScheduleEvent> 

<PublishedStartTime>2006-03-02T20 : 15 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-03-02T21 : 00 : OOZ</PublishedEndTime> 
<ServiceRef IDRef ="dvbipdc : //example . com/Channell"/> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/RingTonelOO"/> 
<ContentLocation>http : //example . com/RingTonelOO .mp3</ContentLocation> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/RingTonel"/> 
<ContentLocation>http: //example . com/RingTonel .mp3</ContentLocation> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/RingTone2 "/> 
<ContentLocation>http: //example . com/RingTone2 .mp3</ContentLocation> 
</ScheduleEvent> 
</ScheduleEventTable> 
<ServiceTable> 

<Service serviceID="dvbipdc : //example . com/Channell" > 
<ServiceName>Channell</ServiceName> 

<ServiceType href = ' urn:dvb : ipdc : esg: cs : ServiceTypeCS : 1 . 3 . 2 ' /> 
<ServiceType href =' urn: dvb : ipdc : esg: cs : ServiceTypeCS : 2 . 2 ' /> 
<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Channell"/> 
</Service> 
</ServiceTable> 
<AcquisitionTable> 

<Acquisition contentMimeType="audio/mp3 " 

acquisitionID="dvbipdc : //example . com/Acquisition/Channell" > 
<ComponentDescription> 

<ComponentCharacteristic xsi : type="FileDownloadComponentType"/> 
<SessionDescription xsi : type="InlinedSDPType" > 
<SDP><! [CDATA[v=0 
o=example . com 751092616 751111042 IN IP6 FE80::1:4D3E 
s=Ring tone download service 
t = 

a=flute-tsi : 9532 
a=f lute-ch: 1 

a=source-filter: incl IN IP6 * FE80 : : 2 : : 70CA 
m=application 12345 FLUTE/UDP 
C=IN IP6 FF15: :1:141B 
] ] ></SDP> 

</SessionDescription> 
</ComponentDescription> 
</Acquisition> 
</AcquisitionTable> 
</ESG> 
</ESGMain> 
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6.6 Webcasting service 

6.6.1 Description 

The webcasting scenario allows delivery of web sites over the broadcast channel. The example below describes the 
announcement of a webcasted site in the ESG data model. 

6.6.2 ESG data model instantiation 

The data model instantiation of a webcasting service points to the root element of the webcasted site, which is usually 
the main html page of the said web site. This is done using the <ContentLocation> element in the ScheduleEvent. The 
ScheduleEvent fragment points to an acquisition fragment which points to the FLUTE session carrying the webcasted 
site. The contentMIMEType attribute in the acquisition fragment should be used to describe the nature of the root 
element of the webcasted site, e.g. be set to "text/html" in the case where the root element is an HTML page. 

The webcasting service is announced as a file download service by setting the ServiceType element within the service 
fragment to: 

urn:dvb:ipdc:esg:cs:ServiceTypeCS: 1.3.2, to announce that it is a download service and 

urn:dvb:ipdc:esg:cs:ServiceTypeCS:2.2, to announce that it is delivered in a download session over a unidirectional 
channel. 

A service fragment is provided, which is used to attract the user to the webcasting service and announce that this service 
is of type download. However, it should be noted that the service fragment does not describe the webcasted sites 
available in the service. This is done by the content fragment. In the data model instantiation of the webcasting service, 
each webcasted site is described by one content fragment. 

Upon selection of a webcasted site by the user, the terminal should tune to the FLUTE session delivering the webcasted 
site and retrieve its root element, along with the related resources necessary to render the root element on the terminal. 
The use of file grouping in the FLUTE FDT as described in clause 6.5 of TS 102 591 [39] helps the terminal identifying 
the appropriate set of files to be fetched in advance. 
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Figure 6-7: Data model instantiation of the webcasting service 

6.6.2.1 Example instantiation 

Below an example instantiation is provided which announces the availability of a webcasted site for some days. 



<ESGMain xmlns="urn:dvb : ipdc : esg: 2 05" xmlns :mpeg7="urn:mpeg:mpeg7 : schema : 2001" 

xmlns : tva="urn: tva : metadata : 2 05" xmlns :xsi="http: //www.w3 . org/2 001/XMLSchema- instance" 
> 
<ESG> 

<ContentTable> 

<Content contentlD="dvbipdc : //example . com/Websitel" > 

<Title xml : lang="en">A given Web site</Title> 
</Content> 
</ContentTable> 
<ScheduleEventTable> 
< ScheduleEvent > 
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<PublishedStartTime>2006-03-01T20 : 00 : OOZ</PublishedStartTime> 
<PublishedEndTime>2006-06-30T20 : 00 : OOZ</PublishedEndTime> 
<ServiceRef IDRef ="dvbipdc : //example . com/Webcasting" /> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/Websitel"/> 
<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Websitel"/> 
<ContentLocation>http : //a . website . com/index . html</ContentLocation> 
</ScheduleEvent> 
</ScheduleEventTable> 
<ServiceTable> 

<Service serviceID="dvbipdc : //example . com/Webcasting" > 
<ServiceName>Webcasting service</ServiceName> 

<ServiceType href =" urn: dvb : ipdc :esg: cs : ServiceTypeCS : 1 . 3 . 2"/> 
</Service> 
</ServiceTable> 
< Acquis! tionTable> 

<Acquisition contentMimeType= " text/html " 

acquisitionID="dvbipdc : //example . com/Acquisition/Websitel" > 
<ComponentDescription> 

<Component Characteristic xsi : type="FileDownloadComponentType"/> 
<SessionDescription xsi : type=" InlinedSDPType" > 
<SDP>< ! [CDATA[v=0 
o=example . com 751092616 751111042 IN IP6 FE80::1:4D3E 
s=WEB Casting service 
t = 

a=f lute-tsi : 9532 
a=f lute-ch: 1 

a=source-filter: incl IN IP6 * FE80 : : 2 : : 70CA 
m=application 12345 FLUTE/UDP 
C=IN IP6 FF15: :1:141B 
] ] ></SDP> 

</SessionDescription> 
</ComponentDescription> 
</Acquisition> 
</AcquisitionTable> 
</ESG> 
</ESGMain> 



6.7 Bundled services 

6.7.1 Description 

The Bundled services scenario is where one or more services are grouped together to provide an offering. A service 
offered for purchase must be a member of a bundle. 

Bundles may also be used for example: 

• Grouping of services based on genre. 

• To provide a list of services to which a brand is assigned. 

6.7.2 ESG data model instantiation 

The following example consists of two services which are available as part of a service bundle. The service bundle 
fragment provides purely attractor information. For information necessary to consume one of the services forming the 
bundle, the referenced service fragment and associated acquisition fragment must be acquired. 
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Figure 6-8: Service bundle data model 



6.7.2.1 



Example instantiation 



The following example shows how bundles may be used by the terminal to restrict the set of services that a user is 
presented based on the provider of the service bundle. 



<ESGMain xmlns="urn:dvb : ipdc : esg: 2 005" xmlns :mpeg7="urn:mpeg:mpeg7 : schema : 2 001" 

xmlns : tva="urn: tva : metadata : 2 05" xmlns :xsi="http: //www. w3 . org/2 00 1/XMLSchema- instance " > 
<ESG> 

<ServiceTable> 

<Service servicelD="dvbipdc : //example . com/Channell" > 

<ServiceName>Channell</ServiceName> 

<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Channell"/> 
</Service> 
<Service serviceID="dvbipdc : //example . com/ChannellOO" > 

<ServiceName>Channel 10 0</ServiceName> 

<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/ChannellOO"/> 
</Service> 
<Service serviceID="dvbipdc : //example . com/Channell2 " > 

<ServiceName>Channel 12 0</ServiceName> 

<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Channell20"/> 
</Service> 
<Service serviceID="dvbipdc : //example . com/Channell3 " > 

<ServiceName>Channel 13 0</ServiceName> 

<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Channell30"/> 
</Service> 
<Service serviceID="dvbipdc : //example . com/Channell2 " > 

<ServiceName>Channel 12</ServiceName> 

<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Channell2 "/> 
</Service> 
</ServiceTable> 
<ServiceBundleTable> 

<!-- Service Bundle provided by "Provider A" --> 

<ServiceBundle serviceBundleID= "dvbipdc : //example . com/ServiceBundle/example" > 
<ServiceBundleName>Example Service Bundle for Provider A</ServiceBundleName> 
<ServiceBundleProvider> 

<ProviderURI>http: //A. com</ProviderURI> 
<ProviderName> Provider A</ProviderName> 
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</ServiceBundleProvider> 

<ServiceRef IDRef ="dvbipdc : //example . com/Channell"/> 
<ServiceRef IDRef ="dvbipdc : //example . com/ChannellOO"/> 
<ServiceRef IDRef ="dvbipdc : //example . com/Channell20"/> 
</ServiceBundle> 
<!-- Service Bundle provided by "Provider X" --> 

<ServiceBundle serviceBundleID="dvbipdc : //example . com/ServiceBundle/example2 " > 
<ServiceBundleName>Example Service Bundle for Provider X</ServiceBundleName> 
<ServiceBundleProvider> 

<ProviderURI>http: //X. com</ProviderURI> 
<ProviderName>Provider X</ProviderName> 
</ServiceBundleProvider> 

<ServiceRef IDRef ="dvbipdc : //example . com/Channell" /> 
<ServiceRef IDRef ="dvbipdc : //example . com/Channell30" /> 
<ServiceRef IDRef ="dvbipdc : //example . com/Channell2 " /> 
</ServiceBundle> 
</ServiceBundleTable> 
<AcquisitionTable> 
<!-- Note: Not all Acquisition fragments are included here --> 
<Acquisition contentMimeType= "application/Flute" 

acquisitionID="dvbipdc : //example . com/Acquisition/Channell" > 
<ComponentDescription> 

<Component Characteristic xsi : type="FileDownloadComponentType"/> 
<SessionDescription xsi : type="InlinedSDPType" > 
<SDP><! [CDATA[v=0 
o=example . com 751092616 751111042 IN IP6 FE80::1:4D3E 
s=TV service 
t = 

a=flute-tsi : 9532 
a=f lute-ch: 1 

a=source-filter: incl IN IP6 * FE80 : : 2 : : 70CA 
m=application 12345 FLUTE/UDP 
C=IN IP6 FF15: :1:141B 
] ] ></SDP> 

</SessionDescription> 
</ComponentDescription> 
</Acquisition> 
</AcquisitionTable> 
</ESG> 
</ESGMain> 



6.8 Subscription based service 

6.8.1 Description 

The subscription based service scenario builds upon the bundled services example by allowing the purchase of the 
bundle. The purchase offer is described using the purchase fragment, which also contains and/or refers to information 
necessary to make the purchase. 

6.8.2 ESG data model instantiation 

This bundle of services data model is extended by adding a purchase fragment which describes the purchase offer 
i.e. the rights that you are buying. In addition the price of the offer is signalled, however this may be a non contractual 
price and the actual price paid is determined by the actual purchase system. The purchase fragment also contains 
information required by the purchase system to make the purchase. The mechanism used is determined by the SPP 
system used. 

The example also instantiates a purchase channel fragment is used to provide information about where the purchase can 
be made. 

Please reference to clause 6.10 for further information on the use of SPP and how it is used within the context of the 
ESG. 
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Figure 6-9: Purchase data model 



6.8.2.1 Example instantiation 

The following example shows how the purchase fragment may be used to describe a purchase offer. It provides 
sufficient information for the terminal to initiate the purchase process. This results in obtaining the rights to consume 
the set of services defined within the bundle referenced by the purchase fragment. 

In addition information may also be provided within the service fragment to enable a terminal to check if it already has 
rights to consume the chosen service. 



<ESGMain xmlns="urn:dvb : ipdc : esg: 2 005" xmlns :mpeg7="urn:mpeg:mpeg7 : schema : 2 001" 

xmlns : tva="urn: tva : metadata : 2 05" xmlns :xsi="http: //www.w3 . org/2 001/XMLSchema- instance" 
xmlns : cl8="http: //www. 18 crypt . com/2 05/XMLSchema" xmlns : roap="urn: oma :bac :dldrm: roap- 
1 . " > 
<ESG> 

<ServiceTable> 

<Service serviceID="dvbipdc : //example . com/Channell" > 
<ServiceName>Channell</ServiceName> 

<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Channell"/> 
<!-- only present for Services encrypted using IBCrypt --> 

<PrivateData xsi : type="cl8 :HorizontalServiceInf ormationType" > 

<cl8 : serviceBaseCID>providerA. example . com/servicel</cl8 : serviceBaseCID> 
</PrivateData> 
<!-- end of 18crypt specific part --> 

</Service> 
</ServiceTable> 
<!-- Schedule Event and Content definitions omitted --> 

<ServiceBundleTable> 
<!-- Service Bundle provided by "Provider A" --> 

<ServiceBundle serviceBundleID="dvbipdc : //example . com/ServiceBundle/example" > 
<ServiceBundleName>Example Service Bundle for Provider A</ServiceBundleName> 
<ServiceBundleProvider> 

<ProviderName>Provider A</ProviderName> 
</ServiceBundleProvider> 

<ServiceRef IDRef ="dvbipdc : //example . com/Channell "/> 
</ServiceBundle> 
</ServiceBundleTable> 
<PurchaseTable> 
<!-- Subscription Purchase Offer --> 
<Purchase> 

<ServiceBundleRef IDRef = "dvbipdc : //example . com/ServiceBundle/example" /> 
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<Price currency="USD" >5</Price> 

<Description xml : lang="en" >Subscribe to the Sports Bundle for 1 Month</Description> 
<!-- OSF specific PurchaseRequest --> 
<PurchaseRequest> 

<DRMSystem>urn:dvb:casystemid: 709</DRMSystem> 
<PurchaseData xsi : type="PurchaseDataType" > 

<Data>u2 34 6 8 9hge3gb3</Data> 
</PurchaseData> 

<PurchaseChannelIDRef IDRef ="dvbipdc : //example . com/PurchaseChannel/RightsShopl" /> 
</ PurchaseRequest > 
<!--18Crypt specific PurchaseRequest --> 
<PurchaseRequest> 

<DRMSystem>urn:dvb : casystemid: 2</DRMSystem> 

<PurchaseData xsi : type="cl8 :HorizontalPurchaseItemType" pltemld="3 " > 
<cl8 :pItemName xml : lang=" en" > Sports Bundle</cl8 :pItemName> 
<cl8 :pItemVersion>42</cl8 :pItemVersion> 
<cl8 :purchaseOption> 

<cl8 : SubscriptionUnit subscript ionTypeEnum=" 2 " subscriptionDuration="PTlM"/> 
<cl8 :UnitText>l Month</cl8 :UnitText> 
</cl8 :purchaseOption> 
</PurchaseData> 

<PurchaseChannelIDRef IDRef ="providerA. example . com/purchaseChannel"/> 
< /PurchaseRequest > 
</Purchase> 
</PurchaseTable> 

<PurchaseChannelTable> 

<PurchaseChannel purchaseChannelID="dvbipdc : //example . com/PurchaseChannel/RightsShopl" > 
<Name>Rights Shop 1</Name> 

<PortalURL>http : //www. RightsShopl . example . com/buy</PortalURL> 
</PurchaseChannel> 

<PurchaseChannel purchaseChannelID= "providerA . example . com/purchaseChannel " > 
<Name xml : lang="en" >PurchaseChannelA</Name> 

<Description xml : lang="en" >Information about a particular Purchase Channel (or shop in 
other words) </Description> 

<PrivateData xsi : type="cl8 : CustomerOperationCentreType" > 
<cl8 : cocID>shopA. example . com/coc</cl8 : cocID> 
<cl8 : cocName xml : lang="en" >shopA</cl8 : cocName> 
<cl8 : cocLocalFlag>true</cl8 : cocLocalFlag> 

<cl8 : cocRekeyingSaf etyWindow>1000</cl8 : cocRekeyingSaf etyWindow> 
<cl8 :cocContactInfo>tel :+44-555-555432</cl8 : cocCont act Info 
<cl8 :cocRiID> 

<keyldentif ier xsi : type="roap :X509SPKIHash" > 

<hash xmlns=' ' >sk+4JImZCG+IV4/c+Pw9FeAbhuc=</hash> 
</keyIdentif ier> 
</cl8 :cocRiID> 

<cl8 : cocRiURL>http: //rightsIssuerA. example . com/abc .php</cl8 : cocRiURL> 
</PrivateData> 
</PurchaseChannel> 
</PurchaseChannelTable> 

<AcquisitionTable> 
<!-- Note: Not all Acquisition fragments are included here --> 
<Acquisition contentMimeType= "application/Flute" 

acquisitionID="dvbipdc : //example . com/Acquisition/Channell" > 
<ComponentDescription> 

<ComponentCharacteristic xsi : type="FileDownloadComponentType"/> 
<SessionDescription xsi : type="InlinedSDPType" > 
<SDP>< ! [CDATA[v=0 
o=example . com 751092616 751111042 IN IP6 FE80::1:4D3E 
s=Ring tone download service 
t = 

a=flute-tsi:9532 
a=f lute-ch: 1 

a=source-f ilter: incl IN IP6 * FE80 : : 2 : : 70CA 
m=application 12345 FLUTE/UDP 
C=IN IP6 FF15: :1:141B 
] ] ></SDP> 

</SessionDescription> 
</ComponentDescription> 
</Acquisition> 
</AcquisitionTable> 
</ESG> 
</ESGMain> 
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6.9 Support of service previews 

6.9.1 Description 

The preview of services may be used to supply additional content to give pre-announcement related to the service. This 
preview of services can be used to attract the user by the service provider even though it consumes additional 
bandwidth. The service provider can provide additional stream such as video clips or audio clips to promote their 
services. On the user side the preview of service helps the user to decide on a service for consumption. 

In this clause, the signalling of preview data in the ESG is described and an example of the terminal behaviour in the 
case of preview information is given. 

The "Related Material" type is used to specify the reference to media assets which related to a service or content. This 
"Related Material" type element is included in several ESG fragments, i.e. service fragment, content fragment and 
service bundle fragment. 

This datatype can be used for different purposes, as the purpose can be signalled by the HowRelated element. In the 
case of preview the HowRelated element is set to urn:tva:metadata:cs:HowRelatedCS:2007:32(Preview) according to 
annex B. 

Basically the preview data is used to describe the related service/content, i.e. simple text for synopsis, a still picture 
showing a snapshot, a short audio/video clip. The "Related Material" also provides the possibility of containing other 
media types, i.e. the URI or logo for promotion of service/content provider, other related information about an 
actor/actress or film clip. This kind of information is not intended as a preview of the service. Therefore the 
HowRelated element should signal if "RelatedMaterial" is used for preview. 

The signalling of previews for services and an example of the terminal behaviour is given in the following clauses. 

6.9.2 ESG datamodel instantiation 

Preview functionality is supported using the RelatedMaterial element with its HowRelated element having the "href" 
attribute set to urn:tva:metadata:cs:HowRelatedCS:2007:32(Preview) as defined in annex B. 

Signalling of preview content is supported within the following ESG fragment types 

• Service - An overview of the services content. 

• ServiceBundle - An overview of the services and content forming the bundle. 

• Content - An overview of the described content. 

As recommended the preview material should not be inlined within the ESG XML fragments, but carried as ESG 
auxiliary data, or available via the interactive channel. 

6.9.2.1 Example instantiation 

The following XML instance is an example of how a preview for a service can be announced using the "Related 
Material" element. 



<RelatedMaterial> 

<HowRelated href= ' urn: tva rmetadata : cs :HowRelatedCS : 2007 : 32 ' /> 

<MediaLocator> 

<mpeg7 :MediaUri>http : //www. example . com/dvb/preview/Thelma%20%26%20Louise .mpg</mpeg7 rMediaUri:; 

</MediaLocator> 
< /RelatedMaterial > 



6.9.3 Terminal behaviour 

In this clause an example of the terminal behaviour is given in the case HowRelated elements signalling preview 
information are received. 

NOTE: as the terminal behaviour is not standardized it is also valid behaviour of the terminal to ignore 
HowRelated elements signalling preview information. 
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When the terminal receives ServiceBundle, service or content fragments, it checks whether there is a RelatedMaterial 
element having a HowRelated element which signals a "preview" option. 

An example for the step wise processing may be as follows: 

1. Receive an ESG fragments 

2. Check the ServiceBundle, Service and content fragment 

3. Check whether the fragments instantiate the "RelatedMaterial" or not. If a fragment instantiates the 
"RelatedMaterial", go to the next. 

4. Check the value of "HowRelated" element in the "RelatedMaterial". If the value of "HowRelated" element is 
signalling preview information according to annex B, go to the next step. 

5. Acquire the preview data using the information received from "RelatedMaterial". See clause 7.5 for more 
details on the expected terminal behaviour in the case of delivery of ESG auxiliary data 

6. When the user requires the preview data of certain services, the referenced data may be shown to the user. 
This may involve communication with a deadend server over the interactive channel. 



6.1 Support of purchase information related to services 

6.10.1 Purchase of services 
6.10.1.1 Description 

Purchase means the acquisition of the rights to consume a certain service which is selected by the user. And also it 
requires access parameters to purchase the services. These purchase information should be acquired from the purchase 
fragment and the purchase channel fragment. The purchase fragment can refer to a service bundle fragment, which 
refers one or more service fragments. The purchase fragment refers to zero or more purchase channel fragments, which 
carry access parameters of the purchase channel. 
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The following steps describe an example of the procedure for a purchase scenario. 

1. A user selects a service. 

2. The terminals checks whether the service is free to air or not. This is enabled by explicit signalling with the 
freeToAir attributes in the service or schedule fragment or implicitly if purchase fragments are attached to the 
service bundle the service is contained in. For simplicity of processing the use of freeToAir and clearToAir 
attributes may be used. 

Note that since both flags have no default values, the terminal can make no assumption about the service being 
free or not - i.e. encrypted or unencrypted - based on the absence of the freeToAir flag - i.e. the clearToAir 
flag. 

2-1 If it is free, consume the service. 

2-2 If not, go to step 3. 

3. The terminal checks the user has the right to consume the service: 
3-1 If the user has it, consume the service. 

3-2 If not, go to step 4. 

4. The terminal traces back the service bundle fragment which includes the selected service. 

5. The terminal shows one or multiple purchase information from purchase fragment which is referred by service 
bundle fragment 

6. The user chooses a purchase option for the selected service. 

7. The access parameters are obtained from the purchase channel fragment which is referred by purchase 
fragment if required. 

8. After the user purchases the service, the user can consume the item. 



6.1 0.1 .2 Example of an ESG data model instantiation 

The example below describes the mapping of the purchase information to the ESG data model. 

This example of purchase item is available only from UTC 1 PM on the 12^^ of April, 2006 to 18 PM on 18^^ of the 
month. The price of the purchase item is 15 Euros or 21 US$, for which the user obtains the rights to view the content 
two times for a period of two days. After the terminal acquire the purchase fragment associated with the selected service 
bundle fragment and service fragment, the offer is presented to the user. The PurchaseRequest element itself is 
depending on the used service protection system. Examples for a PurchaseRequest for OSF based systems and for a 
18Crypt based system are given in clauses 6.9.2.3 and 6.9.3 respectively. The example below shows both an example 
for a OSF specific PurchaseRequest and for a 18Crypt specific one. Both systems can be signalled in the same purchase 
fragment. 



< Purchase start ='2006-04-12T13:00:00Z' end= •2006-04-18T2 3:00:00Z' 
purchaseID= ' dvbipdc : //example . com/Purchase/12458584 ' > 

<ServiceBundleRef IDRef = ' ServiceBundleId_A' /> 

<Price currency= ' EUR ' >15 . 0</Price> 

<Price currency= 'USD' >21 . 0</Price> 

<UsageConstraints> 

<PurchaseType href = ' urn: tva : metadata : cs : PurchaseTypeCS : 2004 rplayCounts ' /> 
<QuantityUnit href = ' urn: tva rmetadata : cs rUnitTypeCS : 2004 rplays ' /> 
< Quant it yRange max= ' 2 ' /> 

</UsageConstraints> 

<UsageConstraints> 

<PurchaseType href= urn: tva rmetadata : cs : PurchaseTypeCS : 2004 rplayForPeriod /> 
<QuantityUnit href= urn: tva rmetadata : cs rUnitTypeCS : 2 004 : day /> 
< Quant it yRange max= ' 2 ' /> 

</UsageConstraints> 

<Description>This is the special offer for Easter</Description> 

<!-- OSF specific PurchaseRequest --> 
< PurchaseRequest > 
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<DRMSystem>urn:dvb: casystemid: 709</DRMSystem> 
<PurchaseData xsi : type= ' PurchaseDataType ' > 

<Data>BISOP1324</Data> 
</PurchaseData> 

<PurchaseChannelIDRef IDRef = ' ChannelUniqueldA' /> 
</PurchaseRequest> 
<!-- ISCrypt specific PurchaseRequest --> 
<PurchaseRequest> 

<DRMSystem>urn:dvb : casystemid: 2</DRMSystem> 

<PurchaseData xsi : type="cl8 :HorizontalPurchaseItemType" pltemld="3 " > 
<cl8 rpItemName xml : lang="en" >Easter Of f er</cl8 :pItemName> 
<cl8 :pItemVersion>42</cl8 :pItemVersion> 
<cl8 :purchaseOption> 

<cl8 : SubscriptionUnit subscriptionTypeEnum="2 " subscriptionDuration="PT48H"/> 
<cl8 :UnitText>48 Hours</cl8 :UnitText> 
</cl8 :purchaseOption> 
</PurchaseData> 

<PurchaseChannelIDRef IDRef ="providerA. example . com/purchaseChannel"/> 
</ PurchaseRequest > 

<MediaTitle> 

<mpeg7 : Titlelmage> 

<mpeg7 :MediaUri>EasterTitle . jpg</mpeg7 :MediaUri> 
</mpeg7 : Titlelmage> 
</MediaTitle> 
</Purchase> 



To purchase the item, a user may be required to make use of a referenced purchase channel which may be Hnked to a 
"Shop". In the above example the OSF purchase makes a reference to a purchase channel fragment with an ID of 
"ChannelUniqueldA", for the ISCrypt system a reference to a purchase channel fragment with an ID of 
"providerA.example.com/purchaseChannel". 

An example PurchaseChannel fragment follows, which defines the "Pear Telecom" shop which a user can contact to 
make a purchase. It should be noted that in some systems an offer may be purchased from more than one "Shop". 



< PurchaseChannel purchaseChannelID= ' ChannelUniqueldA ' > 
<Name>Pear Telecom Purchase Center</Name> 

<Description>This is the sample purchase channel of Pear Telecom</Description> 
<PortalURL>http : //www. example . com/dvb_h/purchase</PortalURL> 
<ContactInfo>+82-2-500-5000</ContactInfo> 
<MediaTitle> 

<mpeg7 : Titlelmage> 

<mpeg7 :MediaUri>example . jpg</mpeg7 :MediaUri> 
</mpeg7 : Titlelmage> 
</MediaTitle> 
< / PurchaseChannel > 



The ISCrypt system defines additional information for the PurchaseChannel. An example for this can be found in 
clause 6.10.3. 

6.10.2 Purchase of protected Services (OSF Based) 
6.10.2.1 Description 

The Open Security Framework provides a generic mechanism for the purchase and Protection of IPDC services, over a 
DVB-H network. 

The OSF system may be used to supports business models such as subscription and Pay Per View, which can either be 
purchased through the IPDC system using information contained within a services associated ESG purchase fragment, 
or via some other means (Phone, WEB, access, etc.) with entitlement distribution being controlled by the Service 
provider. 
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6.10.2.2 Example of an ESG Data Model Instantiation 

The following is an example instantiation, which describes a purchase option allowing access to a set of services 
(defined within a service bundle) for a 24 hour period starting from the time of purchase. 



<Purchase start="2 006-02-2 0T00 : 00 : 00 . OZ" end="2006-04-01T00 : 00 : 00 . OZ" > 
<ServiceBundleRef IDRef ="dvbipdc : //servicebundle/LocalServices" /> 
<Price currency="GBP" >2 . 0</Price> 
<UsageConstraints> 

<PurchaseType href ="urn: tva rmetadata : cs : PurchaseTypeCS : 2004 :playForPeriod"/> 

<QuantityUnit href =" urn: tva rmetadata : cs :UnitTypeCS : 2 004 :day"/> 

< Quant it yRange max="l" /> 
</UsageConstraints> 

<Description xml : lang="en" >1 Day Access to Music Channels</Description> 
<PurchaseRequest> 

<DRMSystem>urn:dvb: casystemid: 709</DRMSystem> 

<PurchaseData xsi : type="PurchaseDataType" > 
<Data> [!CDATA[a3f4c7e8f7b8] ] </Data> 

</PurchaseData> 
</PurchaseRequest> 
</Purchase> 



The "start" and "end" attributes within the purchase element define the period of time over which this purchase offer 
may be purchased. The purchase information should be made available a period of time following the purchase window, 
so that terminals that have already purchased the offer, have access to the metadata associated with the purchase. 

The "ServiceBundleRef" identifies the set of services that the user is purchasing rights of access for. 

The "Price" element defines the cost of the purchase offer within a specified currency. It should be noted that this price 
is non-contractual, and the actual price may differ to that declared within the purchase fragment. 

The "UsageConstraints" element defines the access rights that the user is purchasing. In the above example, the user 
receives rights to consume any service within the referenced service bundle for a 24 hour period. 

The "Description" element provides a text based description of the purchase offer, which is typically displayed on the 
terminal, to attract the user to make the purchase. 

The "PurchaseRequest" element defines KMS specific data required to make a purchase. The KMS for which the data 
within this element is relevant is signalled by the "DRMSystem" element. The URI declared within this element must 
be one registered with DVB. 

The "PurchaseData" element uses an abstract datatype, and in the case of the OSF system the actual XML schema type 
used within this element will be dependant on the CA system declared. In the above example the IPDC declared 
"PurchaseDataType" is used to carry some purchase specific data that is used by the KMS to perform the purchase and 
control access to the purchased service bundle. 

It is possible that there may be multiple "PurchaseRequest" elements present within the purchase fragment, where each 
one is for a different KMS and declares the KMS specific data required to purchase the access rights to the referenced 
service bundle. 

Once the purchase transaction has been completed the terminal then has rights to consume the set of services declared 
within the service bundle. 

6.1 0.2.3 Consuming a previously purchased service 

Once a purchase has been made the terminal must acquire the SDP for the requested service. This may be located by 
acquiring the services acquisition fragment. The SDP may be carried as part of the acquisition fragment or may be 
carried on a separate multicast, which is declared within the acquisition fragment. 

Once the SDP has been acquired the terminal must parse the SDP and locate a a=fmtp:ipdc-ksm entry with a 
IPDCKMSId value equal to that for the CA system from which rights to the service were purchased (declared by the 
"DRMSystem" element within the "PurchaseRequest" element). In the above example the system looks for an 
IPDCKMSId = 709. 

The use of the IPDCOperatorld field is not required by the OSF solution and so may be ignored. 
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The "m=data" entry associated with the above SDP entry declares the IP Address and port on which the keys required to 
decrypt the service are deHvered. 

6.1 0.2.4 Determining rights to consume a service 

It is advantageous to be able to determine if a user has rights to consume a service without having to physically tune to 
the service and acquire the services associated SDP, as this may take some time to do, due to the burst period of the 
DVB-H system. 

To enable a terminal to check a users rights to consume a service, additional information may be included within the 
service fragment using the PrivateData element to enable the checking of rights. 

The following is an example instantiation of a service element showing the use of the PrivateData element. The 
example makes use of a osf:ServiceRightsCheckType which has been defined outside of the ESG specification to 
enable the inclusion of data to perform the rights check. 

The following is an example instantiation of a datatype extending the PrivateDataType which may be used within the 
PrivateData element in the service fragment to enable the inclusion of DRMSystem specific data used to check a users 
rights: 



<ESGMain xmlns="urn:dvb : ipdc :esg: 2 005" xmlns :mpeg7="urn:mpeg:mpeg7 : schema: 2 01" 
xmlns : tva="urn: tva : metadata : 2 005" xmlns :osf ="myCASSystemURI" 

xmlns : esg="urn:dvb : ipdc : esg: 2 005" xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" 
> 
<ESG> 

<ServiceTable> 

<Service serviceID="dvbipdc : //example . com/Servicel" > 
<ServiceName xml : lang="en" >Servicel</ServiceName> 
<PrivateData xsi : type="osf : ServiceRightsCheckType" > 

<osf :DRMSystem>urn:dvb: casystemid: 3456</osf :DRMSystem> 
<osf : Right sCheck xsi : type="esg: PurchaseDataType" > 

<Data>574 6579erfsds6f2f</Data> 
</osf : RightsCheck> 
</PrivateData> 
</Service> 
</ServiceTable> 
</ESG> 
</ESGMain> 



The PrivateData element uses a type defined by the DRM system vendor outside of the scope of the DVB IPDC 
specifications [1] to [8] to carry data necessary to perform a rights check. In the above example the DRM system vendor 
has chosen to make use of the PurchaseDataType specified within the ESG specification to carry an opaque piece of 
data, which is used by the terminals DRM system to check for existing rights to consume the service. 

NOTE: in the case of determination of rights related to the service bundle the information provided in the 
purchase fragments related to that particular service bundle is evaluated. 

6.10.3 Purchase of protected services (18Crypt based) 

All XML examples listed in this clause assume they are included in a XML structure as shown below: 



<ESGMain 

xmlns :cl8="http: //www. IScrypt . com/2 05/XMLSchema" 

xmlns : o-dd="http : //odrl . net/1 . l/ODRL-DD" 

xmlns : o-ex="http : //odrl . net/1 . 1/ODRL-EX" 

xmlns :oma-dd="http : //www.openmobilealliance . com/oma-dd" 

xmlns :ds="http: //www. w3 . org/2000/09/xmldsig#" 

xmlns :xenc="http: //www. w3 . org/2 1/04 /xmlenc#" 

xmlns = "urn :dvb: ipdc :esg: 2 05" 

xmlns : roap= " urn : oma : bac : dldrm : roap -1.0" 

xmlns : tva="urn: tva : metadata : 2 05" 

xmlns :mpeg7="urn:mpeg:mpeg7 : schema: 2 01" 

xmlns :xsi=" http : //www. w3 . org/2001/XMLSchema-instance " > 

<ESG> 

<!— All XML fragments in this chapter go in here unless stated otherwise 

</ESG> 
</ESGMain> 
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The data needed to initiate a purchase is signalled via the service guide in the ServiceBundle, PurchaseChannel and 
purchase fragments. 

In the following example, a bundle of two services ("bundle A") are available for purchase for a 24 hours period. The 
grouping of the two services in one bundle is described by the ServiceBundle fragment: 



<ServiceBundleTable> 

<ServiceBundle serviceBundleID="dvbipdc : //IScrypt/bundleA" > 
<ServiceBundleName>Service Bundle A</ServiceBundleName> 

<ServiceRef IDRef ="dvbipdc : //IScrypt . example . com/service/0815" serviceNumber="l"/> 
<ServiceRef IDRef ="dvbipdc : //IScrypt .example . com/service/0816" serviceNumber="2 "/> 
</ServiceBundle> 
</ServiceBundleTable> 



The service guide defines one or multiple purchase channels to which purchases can be directed. The service operation 
centre and customer operation centre information is also signalled as part of the purchase channel data, in the private 
elements of type CustomerOperationCentreType and ServiceOperationCentreType. 



<PurchaseChannelTable> 

< PurchaseChannel purchaseChannelID= "providerA . example . com/purchaseChannel " > 
<Name xml : lang="en" >PurchaseChannelA</Name> 
<Description xml : lang="en" >Inf ormation about a particular Purchase Channel (or shop in other 

words) </Description> 
<PrivateData xsi : type="cl8 : CustomerOperationCentreType" > 
<cl8 : cocID>shopA. example . com/coc</cl8 : cocID> 
<cl8 : cocName xml : lang="en" >shopA</cl8 : cocName> 
<! --indicates, if 'true', that a COC is local to the SOC, and therefore advertises the availability 
and purchase information completely in the Service Guide. --> 
<cl8 : cocLocalFlag>true</cl8 : cocLocalFlag> 
<!-- is the time interval DT during which it cannot be guaranteed that RO renewal will succeed 
timely for uninterrupted access to a particular service- -> 
<cl8 : cocRekeyingSaf etyWindow>1000</cl8 : cocRekeyingSaf etyWindow> 
<!--a text string that indicates to a user how to contact a COC to initiate an out-of-band purchase 
transaction (e.g. telephone number) . The string can be formatted according to RFC 2806-- 
> 
<cl8 :cocContactInfo>tel :+44-555-555432</cl8 : cocCont act Info 
<!-- ID of the RI associated with Customer Operation Centre --> 
<cl8 :cocRiID> 

<keyldentif ier xsi : type="roap :X509SPKIHash" > 

<hash xmlns=' ' >sk+4JImZCG+IV4/c+Pw9FeAbhuc=</hash> 
</keyIdentif ier> 
</cl8 :cocRiID> 
<!-- URL of the RI associated with Customer Operation Centre --> 

<cl8 : cocRiURL>http: //rightsIssuerA. example . com/abc .php</cl8 : cocRiURL> 
</PrivateData> 
< / PurchaseChannel > 
</PurchaseChannelTable> 



The service bundle is made available for purchase by instantiating the following purchase fragment in the service guide. 



<PurchaseTable> 

< Purchase start ="2006-03-01T00:00:00.0" end= "2006-04-01T00:00:00.0"> 
<!-- The purchase is for the Service bundle A --> 

<ServiceBundleRef IDRef ="dvbipdc : //18crypt .example . com/bundleA"/> 

<Price currency="GBP">2 . 0</Price> 

<Description xml : lang="en" >24 Hour Access to Music Channels</Description> 

<PurchaseRequest> 

<DRMSystem>urn:dvb: casystemid: 2</DRMSystem> 

<PurchaseData xsi : type="cl8 :HorizontalPurchaseItemType" pltemld="3 " > 
<cl8 rpItemName xml : lang="en" >Music Channel 24h</cl8 :pItemName> 
<cl8 :pItemVersion>42</cl8 :pItemVersion> 
<cl8 :purchaseOption> 

<cl8 : SubscriptionUnit subscriptionTypeEnum="2 " subscriptionDuration="PT24H"/> 
<cl8 :UnitText>24 Hours</cl8 :UnitText> 
</cl8 :purchaseOption> 
</PurchaseData> 

<PurchaseChannelIDRef IDRef = "providerA . example . com/purchaseChannel " /> 
</PurchaseRequest> 
</Purchase> 
</PurchaseTable> 
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A connected device instantiates a purchase request with the data obtained from the above fragments as follows (note 
that the element "cl8:socID" contains only the actual service operator centre ID, and not the full URL received from the 
service guide). 



<?xml version="l . 0" encoding="UTF-8" ?> 
<cl8 :purchaseRequest 

xmlns : cl8=" http : //www. IScrypt . com/2 05 /XMLSchema " 
xmlns : xsi = " http : //www . w3 . org/2 l/XMLSchema- instance " 
interf aceVersion= " 1 " > 
<cl8 :user> 

<cl8 :userID>015551233 56</cl8 :userID> 
</cl8 :user> 
<cl8 :device> 

<!-- This is the UDN of the device --> 
<cl8 :deviceID>0044005817853</cl8 :deviceID> 
<cl8 :riDeviceID>1234567890</cl8 :riDeviceID> 
</cl8 :device> 
<cl8 : serviceOperatorCentre> 

<cl8 : socID>1234</cl8 : socID> 

<cl8 : socInfoURL>http: //www. socA. example . com/homepage .html</cl8 : socInfoURL> 
<cl8 : socKeyURL>http: //socA. example . com/keyURL .php </cl8 : socKeyURL> 
<cl8 : riID>sk+4JImZCG+IV4/c+Pw9FeAbhuc=</cl8 : riID> 
<cl8 : riURL>http : //rightsIssuerA. example . com/abc .php</cl8 : riURL> 
</cl8 : serviceOperatorCentre> 
<cl8 :purchaseItemList> 
<cl8 :purchaseltem> 

<cl8 : itemID>3</cl8 : itemID> 
<cl8 : version>42</cl8 : version> 

<cl8 :purchaseOption>2</cl8 :purchaseOption> 
<cl8 : price currency="GBP" >2.0</cl8 :price> 
</cl8 :purchaseltem> 
</cl8 :purchaseItemList> 

<cl8 : signature>h8twx3rvEPO0vKtMup4NbeVu0f 10</cl8 : signature> 
</cl8 :purchaseRequest> 



The subscription management system returns a successful response: 



<purchaseResponse status= ' success ' /> 



The HTTP payload of the response includes a ROAP trigger used to initiate the RO acquisition, after which the device 
is able to decrypt the key material in the KSMs and access the content. 

For an unconnected device, the user initiates an out-of-band purchase using data displayed by the device as received in 
the service guide. 

An example of such a message could be "To purchase this bundle, contact shopA at 0555 555432". 

6.1 0.3.1 Consuming a previously purchased service 

A service encrypted with 1 SCrypt is signalled by using the PrivateData element in the ServiceType fragment. The type 
of the PrivateData element is set to HorizontalServicelnformationType as shown below in the example: 



<ServiceTable> 

<Service serviceID="dvbipdc : //18crypt . example . com/service/0815" clearToAir="f alse" 
freeToAir="false"> 
<ServiceName>ServiceA</ServiceName> 
<ServiceNumber>l</ServiceNumber> 

<ServiceDescription>18Crypt encrypted service </ServiceDescription> 
<AcquisitionRef IDRef ="dvbipdc : //18crypt .example . com/acquisition/ 0815 "/> 
<PrivateData xsi : type="cl8 :HorizontalServiceInformationType" > 

<cl8 : serviceBaseCID>providerA. example . com/service0815</cl8 : serviceBaseCID> 
</PrivateData> 
</Service> 

< Service serviceID="dvbipdc : //18crypt .example . com/service/ 8 16" clearToAir=" false" 
f reeToAir="f alse" > 
<ServiceName>ServiceB</ServiceName> 
<ServiceNumber>2</ServiceNumber> 

<ServiceDescription>service encrypted with 18Crypt</ServiceDescription> 
<AcquisitionRef IDRef ="dvbipdc : //18crypt . example . com/acquisition/0816 " /> 
<PrivateData xsi : type="cl8 :HorizontalServiceInformationType" > 

<cl8 : serviceBaseCID>providerA. example . com/service0816</cl8 : serviceBaseCID> 
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</PrivateData> 
</Service> 
</ServiceTable > 



The HorizontalServicelnformationType adds one element, the ServiceBaseCID. This is the basic identifier of this 
service as used by ISCrypt. The same service can be broadcast on different networks by different broadcasters (called 
Service Operation Centres (SOC) in ISCrypt). A service is uniquely identified by the socID and the ServiceBaseCID. 
There is only one SOC per IP Platform. Information about the SOC including the socID is signalled as a 
PurchaseChannel with a PrivateData field of the type "ServiceOperationCentreType" as shown in the example below: 



<PurchaseChannelTable> 

< PurchaseChannel purchaseChannelID="socA. com/lPPlatf orml234 " > 
<Name xml : lang="en" >ServiceOperationCentreA</Name> 

<Description>This PurchaseChannel describes the ServiceOperationCentre</Description> 
<PrivateData xsi : type="cl8 : ServiceOperationCentreType" > 
<!-- The SOC ID identifies this service operator. It is recommended that the IP Platform ID is used. 
Please note that only the part following http://www.18crypt.com/socID: is the actual ID. 
For the actual SOC ID the restriction in http://www.w3.Org/TR/xmlschema-2/#ID apply --; 
<cl8 : socID>http : //www. 18crypt . com/socID : 1234</cl8 : socID> 
<cl8:socName xml : lang="en" >SOC A</cl8 : socName> 
<!-- The URL through which the SubMgmt can retrieve purchase information from the SOC.--> 

<cl8 : socKeyURL>http: //socA. example . com/keyURL .php</cl8 : socKeyURL> 
<!-- The URL from which an RI can receive service and programme keys --> 

<cl8 : socInfoURL>http: //www. socA. example . com/homepage .html</cl8 : socInfoURL> 
</PrivateData> 
</ PurchaseChannel > 
</PurchaseChannelTable> 



The unique ID for a particular service in the context of a particular SOC is given by concatenating the socID with the 
delimiter "#S" and the ServiceBaseCID. As the Service Encryption Key (SEK) changes over time, this ID isn't enough 
to map a service to a particular SEK. This is done by the service_CID_extension, a 32 bit integer signalled in the key 
stream. In order to identify the correct key the following ID has to be created: 

• service_CID = socID + '#S' + ServiceBaseCID + '@' + hex(service_CID_extension); 
or the binary equivalent 

• service_BCI = HMAC-SHAl-64(socID + '#S' + ServiceBaseCID + '@')«32 I service_CID_extension. 

Given the example from above and assuming a service_CID_extension of 2754 (0x00000AC2) the service_CID would 
be •1234#SproviderA.example.com/service0816@00000AC2'. 



The service_CID_extension is 32 bit long and any leading should be included. 

The service_CID and service_BCI respectively is used to identify the particular SEK used. 

Without any further information it is not possible to identify in advance (before actually consuming the service and 
receiving the key stream) whether the terminal has the rights to consume a particular service/programme as only the 
socID and the ServiceBaseCID is given but not the extension. If a terminal has key material for a given base ID 
(socID + ServiceBaseCID) then this is an indication that the terminal has either the rights to consume the service at 
present or will have the rights to consume the service in the future. Rights object can contain information on the life 
time of the key material (e.g. using the datetime constraint). Given this information it is possible to identify whether a 
terminal will have the rights to consume a service at a given time. Please note that this can only ever be an estimated 
guess as other factors as additional constraints (e.g. the timed count constraint) or unforeseeable key changes might 
restrict the access. 
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6.10.3.2 Signalling of an Rl service 



A Rights Issuer (RI) service carrying BCROs and other RI messages is signalled by using a service with the 
ServiceType of urn:dvb:ipdc:esg:cs:ServiceTypeCS:1.3.1.1 as shown in the example below: 



<ServiceTable> 

<Service serviceID="dvbipdc : //IScrypt . example . com/service/RIServiceA" clearToAir=" true" 
f reeToAir= "true " > 
<ServiceName>RI Service A</ServiceName> 
<ServiceDescription>A Rights Issuer service. This service should not be listed in the normal 

ESG. </ServiceDescription> 
<ServiceType href =" urn: dvb : ipdc :esg: cs : ServiceTypeCS : 1 . 3 . 1 . l"/> 
<PrivateData xsi : type="cl8 :RIServiceDataType" > 
<cl8 :riID> 

<keyldentif ier xsi : type="roap :X509SPKIHash" > 

<hash xmlns=' ' >sk+4JImZCG+IV4/c+Pw9FeAbhuc=</hash> 
</keyIdentif ier> 
</cl8 :riID> 

<cl8 : scheduled>f alse</cl8 : scheduled> 
<!--drmID (OMA 2.0) is the default --> 
<cl8 :drmID>urn:dvb: ipdc : 18crypt rdrmID: 0</cl8 :drmID> 
</PrivateData> 
</Service> 
</ServiceTable> 



NOTE: the Rights Issuer (RI) service identified by the ServiceType urn:dvb:ipdc:esg:cs:ServiceTypeCS:1.3.1.1 is 
a non-visible service and should not be listed in any service listing shown to the user. 

6.11 Zapping support 
6.11.1 Description 

Any streamed service may be complemented by associated zapping support content. The zapping support content may 
be used to bridge the service switching time at the terminal. During this time the content, which is associated with the 
zapping support, will be presented to the user until the content of the selected service becomes available to the terminal. 
Therefore the user has the possibility to get a first impression of the content that is transmitted for the selected service. 

The datatypes that can be used for zapping support depend on whether the zapping support is static or dynamic. The 
main differences between dynamic zapping and static zapping are the transport mechanism and timeliness. 

• Transport mechanism: 

Dynamic zapping content is transported as a separate IP flow in burst separate from that of the selected 
service. 

Static zapping content is transported as part of the ESG. 

• Timely manner: 

Dynamic zapping content is aligned with the content of the selected service. 
Static zapping is transported significantly in advance to the streaming service. 

• Timeliness: 

Dynamic zapping content contains continuously updated snapshots of the service. 

Static zapping content contains one single "static" picture of the current event or current service. 

NOTE: The switching times between the zapping information and the content channel itself depends on the 

terminal architecture. For instance the switching time might depend on the capability of the terminal to 
determine random access point in the AV content in parallel to the decoding of the zapping information. 
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6.1 1 .2 Dynamic zapping 

6.11.2.1 Description 

A dynamic zapping service is a streaming service on a separate IP flow in a separate zapping burst, which contains 
complementary content about the selected streaming service. The content within every received zapping service burst 
will be continuously updated. The following datatypes are available for dynamic zapping: 

• Video: This is a reduced quality copy of the selected service's video component. The video is transported with 
the same protocol stack and restrictions as specified for the selected service. 

• Audio: This is an reduced quality copy of the selected service's audio component. The audio is transported 
with the same protocol stack and restrictions as specified for the selected service. 

• DynamicText: The dynamic text may contain content related to the progress of the selected AV service, such 
as sub-titling, or other textual content. 

Implementation guidelines on the transport of a dynamic zapping service can be found in TS 102 591 [39]. 

In a straightforward terminal implementation, the terminal would wait in parallel for the normal AV stream and for the 
zapping content. The concept of parallel services is described in TR 102 377 [40]. SDP files are expected to be cached 
in the terminal to improve access time. When the zapping burst is received, the data are extracted from the stream and 
inmiediately decoded and displayed. 

6.1 1 .2.2 ESG data model instantiation of dynamic zapping 

If zapping support for a streaming service is available it is signalled in the acquisition fragment of the selected service. 
In this case the ZappingSupport element holds the type of zapping support provided. If the type corresponds to one of 
the above-mentioned dynamic types, dynamic zapping support has to be available and therefore the 
ZappingSupportSessionDescription element is instantiated to enable the identification of a session carrying the zapping 
content. The zapping session is identified by a SDP File, which signals the session in which the described content is 
transported. The zapping service should be received as long as the content from the corresponding streaming service is 
available or the terminal makes a further service change. 

6.1 1 .2.2.1 Example instantiation 

The following is an example of dynamic zapping support where a low bit rate video stream is used to bridge the gap 
between selecting a service and receiving the service. The example shows the SDP for the low bit rate video stream 
being delivered in the same FLUTE session as that of the SDP for the service. This does not imply that it has to be done 
this way. The SDP for the zapping service may be defined inline, carried as auxiliary ESG data, or carried in a file 
within a FLUTE session. 



<ESGMain xmlns="urn:dvb : ipdc :esg: 2 005" xmlns :mpeg7="urn:mpeg:mpeg7 : schema: 2 001" 

xmlns : tva="urn: tva : metadata : 2 005" xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" 
> 
<ESG> 
<ServiceTable> 

<Service servicelD="dvbipdc : //example . com/Channell" > 
<ServiceName>Channell</ServiceName> 

<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Channell" /> 
</Service> 
</ServiceTable> 

< Acquis! tionTable> 

<Acquisition contentMimeType="video/H264" 

acquisitionID="dvbipdc : //example . com/Acquisition/Channell" > 
<ComponentDescription> 

<ComponentCharacteristic xsi : type="VideoComponentType" > 
<CodecCharacteristic> 

<Codec href="urn:dvb:cs:VideoCodecCS:2 006 : 1 . 1 .2"/> 
</CodecCharacteristic> 
<FrameRate>2 5</FrameRate> 
</ComponentCharacteristic> 

<ComponentCharacteristic xsi : type="AudioComponentType" > 
<Codec href="urn:dvb:cs:AudioCodecCS:2 006 : 1 .3 .2"/> 
<Language >en< /Language > 
</ComponentCharacteristic> 
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<SessionDescription xsi : type="SDPRefType" > 
<SDPStream> 

<! [CDATA[v=0 
o=example . com 751092616 751111042 IN IP6 FE80::1:4D3E 
s=SDP Delivery 
t = 

a=flute-tsi : 9532 
a=f lute-ch: 1 

a=source-filter: incl IN IP6 * FE80 : : 2 : : 70CA 
m=application 12345 FLUTE/UDP 
C=IN IP6 FF15: :1:141B 
]]> 

</SDPStream> 
<SDPURI>http: //example. com/defaultSDP</SDPURI> 
</SessionDescription> 
</ComponentDescription> 
<ZappingSupport> 

<Type href =" urn: dvb: ipdc : cs : ZappingSupportCS :2005:2.1"/> 
<ZappingSDP xsi : type="SDPRefType" > 
<SDPStream> 

< ! [CDATA[v=0 
o=example . com 751092616 751111042 IN IP6 FE80::1:4D3E 
s=SDP Delivery 
t = 

a=flute-tsi : 9532 
a=f lute-ch: 1 

a=source-filter: incl IN IP6 * FE80 : : 2 : : 70CA 
m=application 12345 FLUTE/UDP 
C=IN IP6 FF15: :1:141B 
]]> 

</SDPStream> 
<SDPURI>http: //example. com/defaultZappingSDP</SDPURI> 
</ZappingSDP> 
</ZappingSupport> 
</Acquisition> 
</AcquisitionTable> 
</ESG> 
</ESGMain> 



6.11.3 Static zapping 

6.11.3.1 Description 

A static zapping service has its content transmitted as ESG auxiliary data or inlined within the ESG using the 
MediaLocatorType. This data contains complementary content about the selected service, e.g. a still picture giving the 
impression of the main A/V stream. The following two datatypes are declared as classification scheme terms for static 
zapping support. 

• Static picture (urn:dvb:ipdc:cs:ZappingSupportCS:2005: 1 .1): 

• Static text (urn:dvb:ipdc:cs:ZappingSupportCS:2005:1.2): 

6.1 1 .3.2 ESG data model instantiation of static zapping 

If static zapping support is available it is signalled in the acquisition fragment of the main streaming service. In this case 
the element ZappingSupport holds the type of provided zapping support. If the type corresponds to one of datatypes 
which is mentioned in clause 5.9.3, static zapping support has to be available and therefore the MediaLocator element is 
instantiated to signal inlined zapping data. The inlined zapping data can be received from the ESG fragment stream and 
stored as zapping data. This zapping data is displayed when the terminal tunes to a new service. 
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6.1 1 .3.2.1 Example instantiation 



The following is an example instantiation of static zapping using a Picture to bridge the gap between selecting a service 
and receiving the data. 



<ESGMain xmlns="urn:dvb: ipdc :esg: 2 005" xmlns :mpeg7="urn:mpeg:mpeg7 : schema: 2 01" 

xmlns : tva="urn: tva : metadata : 2 05" xmlns :xsi="http: //www. w3 . org/2 001/XMLSchema- instance" 
> 
<ESG> 
<ServiceTable> 

<Service servicelD="dvbipdc : //example . com/Channell" > 
<ServiceName>Channell</ServiceName> 

<AcquisitionRef IDRef ="dvbipdc : //example . com/Acquisition/Channell" /> 
</Service> 
</ServiceTable> 

< Acquis! tionTable> 

<Acquisition contentMimeType="video/H264 " 

acquisitionID="dvbipdc : //example . com/Acquisition/Channell" > 
<ComponentDescription> 

<ComponentCharacteristic xsi : type="VideoComponentType" > 
<CodecCharacteristic> 

<Codec href="urn:dvb:cs:VideoCodecCS:2 006 : 1 . 1 .2"/> 
</CodecCharacteristic> 
<FrameRate>2 5</FrameRate> 
</ComponentCharacteristic> 
<ComponentCharacteristic xsi : type="AudioComponentType" > 
<Codec href="urn:dvb:cs:AudioCodecCS:2 006 : 1 .3 .2"/> 
<Language >en< /Language > 
</ComponentCharacteristic> 

<SessionDescription xsi : type="SDPRef Type" > 
<SDPStream> 

< ! [CDATA[v=0 
o=example . com 751092616 751111042 IN IP6 FE80::1:4D3E 
s=SDP Delivery 
t = 

a=flute-tsi:9532 
a=f lute-ch: 1 

a=source-f ilter: incl IN IP6 * FE80 : : 2 : : 70CA 
m=application 12345 FLUTE/UDP 
C=IN IP6 FF15: :1:141B 
]]> 

</SDPStream> 

<SDPURI>http: //example. com/defaultSDP</SDPURI> 
</SessionDescription> 
</ComponentDescription> 
<ZappingSupport> 

<Type href = "urn :dvb: ipdc : cs : ZappingSupportCS : 2 005 : 1 . l"/> 
<MediaLocator> 

<mpeg7 : InlineMedia type= ' image/ jpg ' > 
<mpeg7 :iy[ediaData64 > 
/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB 
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2WBDAQEBAQEBAQEBAQEBAQEB 
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAAR 
CAAGAAgDAS I AAhEBAxEB / 8 QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgc I CQoL / 8 QAt RAA 
AgEDAw I E AwUFBAQAAAF 9 AQ I DAAQRBR I hMUEGE 1 FhBy JxFDKBkaE 1 1 KxwRVS f AkM2 JyggkK 
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWVlhZWmNkZWZnaGlqc3Rldnd4eXqDhIWG 
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8j JytLTlNXW19jZ2uHi4+Tl 
5ufo6erx8vP0 9fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA 
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk 
NOEl8RcYGRomJygpKjU2Nzg50kNERUZHSElKUlRVVldYWVpjZGVmZ2hpanNOdXZ3eHl6goOE 
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPUldbX2Nna4uPk 
5ebn6Onq8vP0 9fb3+Pn6/9oADAMBAAIRAxEAPwD8X6KKK/ynP+/g/9k= 
</mpeg7 :MediaData64> 
</mpeg7 : InlineMedia> 
</MediaLocator> 
< /ZappingSupport > 
</Acquisition> 
</AcquisitionTable> 
</ESG> 
</ESGMain> 
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Terminal behaviour 



In this clause the behaviour of the terminal on reception of ESG data is discussed. Clause 7.1 describes the ESG 
bootstrap operation followed by clause 7.2 on how the terminal should join an ESG delivery session. Clause 7.3 
explains the announcement of ESG containers to enable the terminal to monitor changes and updates of ESG containers. 
A possible caching strategy is addressed in clause 7.4 with further details on caching of ESG fragments in clause 7.5. 
The processing of indexes to optimize fragment access is found in clause 7.6. Clause 7.7 contains the recommended 
terminal behaviour when errors in the transmission of the ESG occur. The processing of an actual ESG data model 
instance with possible entry points and navigation use cases is explained in clause 7.8. The last clause 7.9 contains 
references on how initialisation information can be obtained from the ESG data model for applications that consume 
services. 



7.1 Bootstrap 



ESG bootstrap is the operation through which the terminal discovers which ESGs are available and how to acquire 
them. 

Before the actual ESG bootstrap operation can take place the terminal has to connect to a DVB-H transport stream and 
select a particular IP platform, How the particular IP platform is selected is implementation dependant, it might be fixed 
in the implementation, selected by the user or selected by other means. From the PSI/SI tables the terminal receives the 
location (PID) where the IP stream with the well-known IP address for the ESG bootstrap information of that IP 
platform is located (see TR 102 469 [38]). 

From the ESG bootstrap information the terminal can determine the number of ESGs that are available on that IP 
platform, the identification thereof and the acquisition information to access a particular ESG. 

Two descriptors are involved in the bootstrap process: 

• ESGProviderDiscovery Descriptor; and 

• ESGAccessDescriptor. 

Both descriptors are delivered through a FLUTE session with a well-known (registered) destination IP address and port 
(224.0.23.14 for IP Version 4 and FF0X:0:0:0:0:0:0:12D for IP Version 6 on port 9214 defined in TS 102 471 [1] 
clause 10.2). Furthermore, this session is the only one sent to that address and port, so that the terminal does not require 
any additional information e.g. TSI of the session to start the bootstrap process. 

The ESGProviderDiscovery is an XML file whose aim is to inform terminals and users about the various ESG providers 
that deliver ESGs in a given IP Platform. It provides a textual description of the ESG providers, allowing the user to 
easily select one of the ESGs. This file is expected to be carouselled at a low rate (e.g. each 10 s). The 
ESGProviderDiscovery includes a ProviderlD, which is a unique identifier in the scope of the IP platform associated 
with each described ESGProvider. 

NOTE: The terminal should be aware that the ProviderlD may be reused after a certain time period of not using it 
by the entity that manages the bootstrap channel as described in clause 8.1. 

After the user has selected a particular ESG, the terminal uses the ProviderlD to identify a particular ESGEntry within 
the ESGAccessDescriptor file, which contains information on how to acquire the ESG. 

The ESGAccessDescriptor is used by the terminal to fetch information on how to acquire the ESG of a given provider. 
Therefore the ESGAccessDescriptor file contains ESGEntries for each provider identified by ProviderlD. An ESGEntry 
contains information on the FLUTE session (IP Version, SourcelP Address, DestinationIP Address, Port and TSI) and 
the delivery mode (multiple or single stream transport) of the ESG of a given provider. If the Multiples treamTransport 
field is set to the terminal should follow the recommendations of clause 7.2.1, if it is set to 1 the terminal should 
follow recommendations of clause 7.6.2. 

The ESGAccessDescriptor is intended to be carouselled at a high rate (e.g. less than 1 second), and it is encoded in a 
binary format in order to reduce both bandwidth and terminal processing time. 
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The combination of these two mechanisms allows for the following: 

• The first time a terminal connects to the ESG Bootstrap FLUTE session, it discovers the available ESG 
providers in the ESGProviderDiscovery descriptor. It selects one and then parses the associated ESG Access 
descriptor. As this happens during initialization, the terminal/user can accept a short delay, thus allowing the 
ESGProviderDiscovery information to be carouselled at the low rate mentioned above. 

• Next time the terminal connects to a particular IP Platform, in a reasonable amount of time, it can assume that 
the previously stored information of the ESGProviderDiscovery descriptor is still valid. While parsing the 
ESGAccessDescriptor, the stored information can be used to immediately access an ESG of an already 
discovered ESG provider. If the ESG matching a users preference is not presently being delivered, or if 
another ESG not described in the stored information is wanted, the terminal may restart the process of 
acquiring and parsing the ESGProviderDiscovery descriptor. 

It is assumed that at a given time there is only one ESG delivered in an IP Platform by a given ESG Provider, in the 
scope of that IP Platform and a given IP version. If in the real world an ESG Provider is providing different ESGs it is 
expected that it differentiates the ProviderURI. 

It may be assumed that there is only one ESGProviderDiscovery descriptor and one ESGAccessDescriptor per bootstrap 
session for IPDC ESGs, and each is sent as a separate file. However, it should be noted that nothing prevents several 
ESGAccessDescriptor to be available on a given bootstrap session when ESG(s) of different type(s) are advertised 
(e.g. ESGs based on a specification different from TS 102 471 [1]). 

If there are ESG provider logo files referenced from the ProviderLogo element in the ESGProviderDiscovery descriptor 
file, the terminal may parse the FDT of the bootstrap session to locate these files in this FLUTE session. If the logo files 
are not transmitted within the ESG bootstrap session and the URI in the ProviderLogo element is a URL, the terminal 
can assume that the files are only available over the interactive channel. 

As defined in clause 5.1 of TS 102 470 [5], within one IP platform, only one IP version SHOULD be used. In case, 
within a given IP platform, IP Version 4 and IP Version 6 are used, it is not recommended to mix IP versions in the 
same SDP instance according to TS 102 591 [39] clause 6.1.1.2. The only exception being the "o=" field since e.g. an 
IPv4 host can generate SDP for IPv6 sessions. In the case of ESG transport and instantiation the use of IP addresses is 
limited to three places: 

a) the ESGAccessDescriptor in the ESG bootstrap session; 

b) the ESG session partition declaration; and 

c) SDP files. 

When the ESG session partition declaration is used, IPv4 and IPv6 in the same instance is not supported, see 
clause 8.4.2.1 of TS 102 471 [1]. 

The terminal should assume that the bootstrap session contains an ESGAccessDescriptor which holds ESGEntries using 
the same IP Version that is used for the bootstrap session itself. 

The terminal should assume that ESG XML fragments contain or reference exclusively SDP files with source and 
destination addresses of one IP version only, and are transported using that IP version. 

On the terminal side it is recommended that the terminal uses only ESG Entries in the ESGAccessDescriptor which use 
the same IP version as is used for the transport of the bootstrap session. Accordingly it is recommended that the 
terminal uses only addressing within SDP files based on the same IP version as is used for the transport of the ESG. 

Examples of the ESGProviderDiscovery descriptor and the ESGAccessDescriptor are given in clause 7.1. 



7.2 Joining an ESG session 



After the user selects an ESG provider the associated ESGEntry contains the MultipleStreamTransport field that 
indicates which transport mode is used. In the case of ESG single stream transport, a particular ESGEntry in the 
ESGAccessDescriptor describes the FLUTE session carrying all ESG containers of a particular ESG. In the case of 
multiple stream ESG transport, a particular ESGEntry in the ESGAccessDescriptor describes the FLUTE Session 
carrying the ESG announcement carousel. 
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7.2.1 Single stream transport 



If the MultipleStreamTransport field within the selected ESGEntry of the ESGAccessDescriptor set to then single 
stream transport is used for ESG delivery. 

In the single stream mode, the ESG containers are delivered within one FLUTE session. However the SDP files may be 
transported in one or more additional FLUTE sessions (see TS 102 591 [39] for details). 

When tuning to an ESG single stream session the terminal can determine the ESG containers available as Transport 
Objects (TO) in the FLUTE session via the not expired FDT instances. The "FullFDT" attribute, when set to true, 
signals to the terminal that the FDT instance contains the exact set of Transport Objects (TO) that are currently 
scheduled for transmission, and that this transport session carries a consistent ESG XML fragment set describing the 
whole ESG instance at that point in time. For a detailed specification see clause 8.1.4 of TS 102 471 [1]. 

Different notions of ESG container processing as well as version handling are given in clauses 7.4 and 7.5. 



7.2.2 Multiple stream transport 



If the MultipleStreamTransport field within the selected ESGEntry of the ESGAccessDescriptor is set to 1 then multiple 
stream transport is used for ESG delivery. In the multiple stream mode the transport of ESG fragments is split over 
multiple FLUTE sessions. Therefore the terminal should tune to the announcement carousel described in the session 
information of the given ESGEntry to receive the ESG init container. The ESG init container holds the ESG session 
partition declaration that defines the criteria used to determine on which FLUTE session particular ESG fragments are 
delivered. 

Examples of such criteria are "number of hours" and the "ServicelD" for which the ESG information is relevant. These 
criteria can be applied independently or simultaneously. Examples of ESG session partition declarations are given in 
clause 8.2.2.3. 

It is possible that the set of FLUTE Sessions over which the ESG is delivered and the criteria used for the allocation of 
fragments to FLUTE sessions may change over time. Therefore the terminal should detect changes to the partition 
declaration by monitoring for a version change to the ESG init container. 

It is recommended that only one FDT instance is transmitted at a given time in the ESG announcement FLUTE session 
and to set the FullFDT attribute of the FDT instance to "true". 

If an index is present in the ESG announcement FLUTE session the terminal can assume that the ESG fragments 
declared within the index represents all ESG fragments currently scheduled for transmission. 

NOTE: Also in the multiple stream transport case the FDT instance with FullFDT attribute set to "true" contains 
all Transport Objects (TO) that are currently scheduled for transmission in that particular FLUTE session. 

In the remaining clauses, examples are given of possible terminal behaviour when particular ESG session partition 
declaration criteria are used. 

7.2.2.1 Session partitioning criteria, based on a window of time for which the 
fragments are valid 

The terminal can identify for which time period a particular session is relevant by checking "start_field_value" or 
"end_field_value". The presence of the start_field_value depends on the value of the "overlapping" field. 

If the terminal just wants to consume a specific part of the ESG data relevant for a certain time period (e.g. next 2 hours, 
next week), the terminal may select the appropriate ESG FLUTE session to tune to, from the ESG session partition 
declaration and acquire the set of ESG fragments. 

7.2.2.2 Session partitioning based on ServicelD 

The terminal can generate a local session index by checking "start_field_value" or "end_field_value". The presence of 
the start_field_value depends on the value of the "overlapping" field. For the "start_field_value" and "end_field_value" 
an alphabetical ordering is considered. 
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If the terminal just wants to consume a specific part of the ESG data relevant to a certain ServicelD, the terminal may 
select the appropriate ESG FLUTE session to tune to, from the ESG session partition declaration and acquire the set of 
ESG fragments. 




_start_field_value[N][y] = 
_start_field_value[N-1 ][y] 



no 

▼ 



_end_field_value[N][y] = 
end_field_value[N][y] 



For each Partition 
Criteria y 



For eacii Partition 
Criteria N 



-yes- 



_start_field_value[N][y] = 

lowest possible value 

for data type 



_start_field_value[N][y] = 
end_field_value[N-1][y] 



_start_field_value[N][y] = 
start_field_value[N][y] 



_reset=1 



Variables starting 

with '_' are 
implementation 
internal variables 



end 



Figure 7-1 : Flow diagram to determine start_f ield_value and end_field_value of ranges, which 
characterize ESG Partitions with respect to particular criteria 
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7.2.2.3 The case of overlapping partitions 

The ESG multiple stream transport allows that partitions of the ESG transported in separate sessions can overlap with 
respect to a particular partition criterion. Be aware that the overlapping flag in the ESG session partition declaration 
defined in TS 102 471 [1] enables to set start_ and end_ field_values of each rule for each partition. Thus the signalled 
partitions can but do not have to overlap in this case. 

In the case where a partition declaration sets the overlapping field to "0", this signals that all ESG fragments which are 
relevant only to one partition, will only be delivered in the FLUTE session this partition is referring to. 

When the overlapping field is set to "0" in the partition declaration then a start_field_value of a declared partition is 
assumed to be equal to the end_field_value of the previously declared partition without explicit signalling. The previous 
partition is the previous one according to an increasing alphanumeric or numeric order of partitions with respect to a 
particular criterion. If more than one criterion is used also the order of the criteria signalled in the partition declaration 
has to be taken under account (see figure 7-1). Starting from the first criterion of a particular partition, for each criterion 
it has to be checked if: 

a) the end_field_value are the same for the previous partition, thus the range with respect to this criterion is the 
same as for the previous partition; or 

b) the end_field_value is higher than the one for the previous partition, thus the range starts from the 
end_field_value of the previous partition and ends with the end_field_value signalled for this partition. 

If for the particular partition once case b) is signalled all ranges with respect to the following criteria start with the 
minimal value of the particular criterion. However the ranges of the already processed criteria of that partition will start 
as previously described in case a). 

When the overlapping flag is set to "0" the terminal can assume that the session announced, for a given criteria will 
contain all fragments that meet the value range for the criteria announced for the partition. For example if a ESG server 
has partition the ESG data based on time, and the first partition covers the time period, now --12 hours. If the terminal 
requires all fragments which are valid for the next 6 hours it is only required to parse the fragments carried on the ESG 
fragment stream announced by the first partition. 

In the case where the overlapping flag is set to "1" the terminal may tune to all ESG fragment streams in which the 
required fragments may be carried according to the partition declaration, to ensure that it acquires all the fragments 
meeting the required criteria. 

In the case multiple criteria for partitioning are used and there is a particular partition in which a particular criterion 
does not apply, the range of the particular criterion in the particular partitions is set from minimum to maximum value. 

NOTE: The ESG session partition declaration is discussed in more details including regular examples in 

clause 8.2.2. It is not recommended that the ESG server sets the overlapping field to "0" in the case where 
multiple criteria are used. However if it is signalled the following example gives a guideline how to 
interpret the partition declaration. 

The following is an example for a partition declaration based on transmission time and Serviceld, where the ESG 
fragments are delivered across four ESG FLUTE sessions and the ESG announcement session. The first containing all 
ESG fragments which are valid during the next 6 hours for all Servicelds up to "dvbipdc://m". The second contains all 
ESG fragments which are valid during the next 6 hours for services with a Serviceld between "dvbipdc://m" and 
"dvbipdc://z". The third contains all ESG fragments which are valid between 6 hours and 24 hours from now, for 
services with all Serviceld up to "dvbipdc://r". The fourth and final, contains all ESG fragments which are valid 
between 6 hours and 24 hours from now, for services with a Serviceld between "dvbipdc://r" and "dvbipdc://z". 
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Field_identifier = 0x00 



Field_identifier = 0x01 



IP stream=1 



Start_field_value=0 
End field value=0x0006 



Start_field_value="" 
End_field_value="dvbipdc://m" 



IP stream=2 



Start_field_value=0 
End field value=0x0006 



Start_field_value="dvbipdc://m" 
End_field_value="dvbipdc://z" 



IP stream=3 



Start_field_value=0x0006 
End field value=0x0018 



Start_field_value="" 
End_field_value="dvbipdc://r" 



IP stream=4 



Start_field_value=0x0006 
End field value=0x0018 



Start_field_value="dvbipdc://r" 
End_field_value="dvbipdc://z" 



Figure 7-2: Example of partitioning based on two partition criteria and overlapping set to "false" 
Table 7-1 : Example of partitioning based on two partition criteria and overlapping set to "false" 



Field name 


Value 


Description 


num fields 


0x2 


2 partition criteria 


overlapping 


"0" 


No overlapping of partitions 


reserved 


"1111111" 




field_identifier[0] 


0x0000 


Number of hours criterion 


field_encoding[0] 


0x0101 


Hours represented using an inline unsigned short value 


field length[0] 


0x02 


2 Bytes 


field identifier[1] 


0x0001 


Service ID criterion 


field encoding[1] 


0x0000 


Serviceld represented as a inline string 


field length[1] 


0x00 




n IPStreams 


4 


Number of ESQ FLUTE sessions forming the ESG 


IPVersione 


"0" 


IPV4 


Reserved 


"1111111" 




IPStreamlD[0] 


0x01 


Unique identifier for the ESG FLUTE session 


ESGSourceAddress[0] 


OxCAFEBABE 


Source IP address of the ESG FLUTE session 


IPAddress[0] 


OxEEADBEEF 


Destination IP address of the ESG FLUTE session 


Port[0] 


0x0120 


Port used by the FLUTE session 


SessionlD[0] 


0x0100 


TSI of the FLUTE/ALC session 


end field value[0][0] 


0x0006 


ESG fragments valid from now to +6 hours 


length[0][1] 


OxOC 


Length of the following string including the 
Null-termination 


end_field_value[0][1] 


"dvbipdc://m" 


All ESG fragments for services identified by URIs up to 
the value "dvbipdc://m" 


IPStreamlD[1] 


0x02 


Unique identifier for the ESG FLUTE session 


ESGSourceAddress[1] 


OxCAFEBABE 


Source IP address of the ESG FLUTE session 


IPAddress[1] 


0XEEADBEE5 


Destination IP address of the ESG FLUTE session 


Port[1] 


0x0120 


Port used by the FLUTE session 


SessionlD[1] 


0x0101 


TSI of the FLUTE/ALC session 


end field value[1][0] 


0x0006 


ESG fragments valid from now to +6 hours 


length[1][1] 


OxOC 


Length of the following string including the 
Null-termination 


end_field_value[1][1] 


"dvbipdc://z" 


All ESG fragments for services identified by URIs from 
"dvbipdc://m" up to the value "dvbipdc://z". There is an 
assumption within this example that there are no 
services with a Serviceld greater than this value 


IPStreamlD[2] 


0x02 


Unique identifier for the ESG FLUTE session 


ESGSourceAddress[2] 


OxCAFEBABE 


Source IP address of the ESG FLUTE session 


IPAddress[2] 


0XEEADBEE4 


Destination IP address of the ESG FLUTE session 


Port[2] 


0x0120 


Port used by the FLUTE session 


SessionlD[2] 


0x0102 


TSI of the FLUTE/ALC session 


end_field_value[2][0] 


0x0018 


ESG fragments valid from +6 hours to +24 hours. The 
+6 hours is inferred from the previous part of the 
partition declaration 


length[2][1] 


OxOC 


Length of the following string including the 
Null-termination 
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Field name 


Value 


Description 


end_field_value[2][1] 


"dvbipdc://r" 


All ESG fragments for services identified by URIs up to 
the value "dvbipdc://r" 


IPStreamlDfSl 


0x03 


Unique identifier for the ESG FLUTE session 


ESGSourceAddress[3] 


OxCAFEBABE 


Source IP address of the ESG FLUTE session 


IPAddress[3] 


0XEEADBEE3 


Destination IP address of the ESG FLUTE session 


Port[3] 


0x0120 


Port used by the FLUTE session 


SessionlD[3] 


0x0103 


TSI of the FLUTE/ALC session 


end_field_value[3][0] 


0x0018 


ESG fragments valid from +6 hours to +24 hours. The 
+ 6hours is inferred from the previous part of the 
partition declaration 


length[3][1] 


OxOC 


Length of the following string including the 
Null-termination 


end_field_value[3][1] 


"dvbipdc://z" 


All ESG fragments for services identified by URIs from 
"dvbipdc://r" up to the value "dvbipdc://z". There is an 
assumption within this example that there are no 
services with a Serviceld greater than this value 



7.3 Announcement of available ESG containers 

When initially an FDT instance is received a terminal can determine: 

• ESG containers that are available. The ESG containers are signalled by the presence of a "File" element in the 
FDT instance with the attribute Content-Type="application/vnd.dvb.esgcontainer"; 

• all ESG containers currently scheduled for transmission signalled in the FDT instance if the "FullFDT" 
attribute of that instance is set to true; 

• when signalled FDT instance with FullFDT set to "false" expires according to the value set in the expires 
attribute. 

When a new FDT instance is available (identified by a new FDT instance ID) a terminal can determine: 

• which ESG containers have been removed from this session, if the "FullFDT" attribute is set to "true". The 
removal is signalled for each ESG container by the absence of a "File" element with its "Content-Location" 
attribute set to that assigned to the original ESG container e.g. "urn:dvb:ipdc:esg:cid:3"; 

• which ESG containers have been added. This is signalled for each ESG container by the presence of a "File" 
element with a previously unknown "Content-Location" attribute; 

• which ESG containers have been updated. This is signalled by a change to the TOI value, defined within the 
file element used to signal the delivery of an ESG container. 

NOTE: There are no explicit means for the server to signal to the terminal that ESG containers are deleted except 
the FullFDT attribute of FDT instance is set to "true". However the terminal may assume that the content 
of the ESG container can be deleted if a FDT instance has expired and the ESG containers described 
therein are not declared in a new FDT instance which has not expired. 



In order to avoid the FDT instance ID wraparound problem, the Expires attribute of a given delivered FDT instance 
should be lower than the time the server will take to create 2^^ (2^^ = 5! 
instance (i.e. --6 days in case FDT instance is updated once a second). 



should be lower than the time the server will take to create 2^^ (2^^ = 524 288) new FDT instances after this given FDT 



In this case IDs of two unexpired FDT instances can be compared using 20 bit signed arithmetic. FDT instance with ID 
A is newer than FDT instance with ID B, if A - B > 0. 

Under the condition that the files are received in the order they were send and the FullFDT flag in FDT instances are set 
to "true" the wraparound problem does not exist because a FDT instance with Full FDT attribute "true" always declares 
the latest consistent and complete set of files. 



ETSI 



62 ETSI TS 1 02 592 V1 .1 .1 (2007-1 0) 

7.4 Caching of Transport Objects (TO) 

This clause describes a possible caching mechanism for ESG data without having to parse the ESG data. The described 
caching mechanism is generally applicable to both, single or multiple stream ESG delivery. 

The following example shows how the information associated with a Transport Object (TO) carrying an ESG container 
may be used to determine if a cached Transport Object (TO) is still valid when rejoining an ESG Session. 

Initialisation in the general case 

On first joining an ESG session the terminal may cache the Transport Objects (TO) currently being delivered. To 
minimize the number of Transport Objects (TO) that need to be acquired when the ESG session is again accessed, the 
terminal may, also cache the Transport Objects (TO) associated: 

1 . Content-Location value 

2. TOI value 

3. FDT instance ID assigned to the FDT in which the Transport Object was announced (see clause 8.2.1.1 for 
signalling of ESG container updates) 

These may be later used to determine the Transport Objects (TO) that have changed/added/deleted since the ESG 
session was last accessed. 

In addition the FDT instance ID may also be stored and used at a later date to determine if anything within the ESG 
session has changed. This is achieved by comparing the current FDT instance ID with that of the stored value. If they 
are not equal then a change has occurred. 

Initialisation in the case where SplitTOI is signalled 

In the case where the SplitTOI mechanism is signalled for a particular TOI in a FDT instance it can be sufficient to 
conduct the following steps: 

1. identify the file element in a FDT instance describing the Transport Object based on the TOI and determine the 
Version-ID-Length attribute in that file element or if not present in that element the Version-ID-Length 
attribute of the FDT-Instance element, 

2. store TOI, Content-Location, Content-Type, Content-Encoding and Version-ID-Length for the received 
Transport Object. 

Caching of new Transport Objects (TO) 

On identification of a Transport Object (TO) that the terminal currently does not have cached, the terminal may perform 
the following steps to ensure that it is a Transport Object (TO) that should be cached: 

1 . Determine if the Transport Object contains a new version of an already cached ESG fragment container: 

a. In the case where Split TOI is not used, if the following two conditions are met the Transport Object 
will contain a new version of an ESG fragment container: 

• A Transport Object with the same Content-Location attribute has already been cached. 

• The FDT instance ID assigned to the FDT in which the Transport Object is signalled, is a 
subsequent FDT instance. 

b. In the case where split TOI is used, if the following two conditions are met the transport will contain a 
new version of an ESG fragment container: 

• A Transport Object which has the same value for the N most significant bits of the TOI 
value to that of the cached Transport Object. Where N is the number of bits assigned 
within the TOI value to signal the container ID. 

• The ESG fragment container has a subsequent version signalled in the remaining least 
significant bits of the TOI, to that of the ESG fragment container in the cached Transport 
Object identified in the previous step. 
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NOTE: In the case of not monitoring for a significant amount of time the ESG session it is safest to process the 
steps described in l.a) to avoid wrap around problems in the signalled version. 

2. If it contains a new Version of an ESG fragment container, then update the cache by acquiring the new 
Transport Object and deleting the one containing the previous version of the ESG fragment container. 

3. If it does not contain a new version of an ESG fragment container cache the Transport Object as it has been 
described in the initialisation step above. 



7.5 Processing and caching of ESG fragments 

Within the ESG container, the fragment management information declares the set of ESG fragments that can be found 
within the ESG container. The fragment management information announcing for each ESG fragment, its type and its 
location within the ESG data repository. At the level of the ESG container the notion of an ESG fragment, does not only 
cover ESG XML fragments, but can also describe auxiliary ESG data and private auxiliary data. 

It is possible that each ESG container may only carry a specific type of ESG fragment, but the terminal should not 
assume this. 

Upon acquisition of an ESG container the terminal should first look for the fragment management information. 
Typically the fragment management information will be the first structure instantiated in the ESG container (for 
processing efficiency reasons), however the terminal should not assume this, and should use the structure_type and 
strcture_ptr fields in the ESG container header to identify the location of the fragment management information 
structure within the ESG container. Additionally, as per TS 102 471 [1], clause 7.3, there shall be only one fragment 
management information structure per ESG container. 

Similarly, note that according to table 7.2 in TS 102 471 [1] it is only possible to signal one data repository and one 
ESG data repository in a single ESG container as the structure_id field in both cases is limited to "0x00". 

7.5.1 Processing and caching of ESG XML fragments 

Upon parsing of the fragment management information the terminal identifies and can access individual ESG XML 
fragments in the ESG data repository. The type of the ESG XML fragment can be determined from the encapsulation. 
The terminal then has the opportunity to extract the ESG XML fragment from the ESG container and cache it in a local 
repository. This allows fast access to ESG XML information with limited processing effort for caching. 

There are two kinds of identifier for the terminal to keep track of a given ESG XML fragment: 

• the fragmented of the ESG fragment which is in this case an ESG XML fragment. This identifier is transport 
related, and is used to identify the ESG XML fragment within the ESG fragment stream; 

• the URI that is used to identify the ESG XML fragment it is contained in. This URI is used to identify the ESG 
XML fragment within the received instance of the ESG datamodel. 

The terminal can maintain the local ESG XML fragment repository as it is described in the following. When the 
terminal detects that a given ESG container has been updated, deleted, or a new ESG container is transmitted, it can 
track the changes in the fragment management information and check whether a particular ESG XML fragment has 
been updated, inserted or deleted, using the fragment_version and fragmented fields: 

• If a given fragmented has been removed from the received version of the ESG container, this means the 
corresponding ESG XML fragment can be deleted from the ESG XML fragment repository. 

• If a given fragmented has been added, in the received version of the ESG container, this means a new ESG 
fragment is available. The terminal determines based on the esgeragmenteype in the fragment_reference field 
if that ESG fragment is of type ESG XML fragment. If this is the case the terminal caches the data in the ESG 
XML repository and stores the related IDs and, if applicable, related data from the data repository of the 
received ESG container. 

• If a new version of an ESG XML fragment is available the cached ESG XML fragment that corresponds to the 
given fragmented is updated with the ESG XML fragment and, if applicable, related data from the data 
repository. 
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NOTE: In the case of textual representations of ESG XML fragments (see also clause 8.4. 1 .2) the following 
processing of ESG XML fragments is recommended: 

■ The terminal should ignore any unknown elements or attributes, and the content thereof, which 
might be declared in a namespace that it does not support. 

■ In case a declaration within a ESG XML fragment defines a different binding of a namespace 
prefix that is already defined in the textual Decoderlnit, the terminal is not required to support the 
redefinition. 

■ If the terminal requires character encoding information for textual ESG XML fragments in which 
the XML declaration is not present it should use the encoding information provided in the ESG init 
message. 

7.5.2 Processing and caching of ESG auxiliary data 

Upon parsing of the ESG data repository, the terminal identifies individual auxiliary data and can determine their type 
from the data repository. The terminal then has the opportunity to extract the auxiliary data from the ESG container and 
cache it in the terminal. This allows faster access to an auxiliary data once it is needed. The auxiliary data is identified 
by a URI located in the data repository. This URI is used by the ESG to reference the auxiliary data. 

Examples of auxiliary data are image, audio, video, HTML, or SDP files. The terminal can identify the type of the 
auxiliary data using the MIME type. 

There are two kinds of identifier relationships for the terminal to keep track of for a given auxiliary data object: 

• the URI of the auxiliary data, as mentioned above, which is used to identify the auxiliary data within the ESG 
(note that clause 8.4.3 provides guidelines on how to the terminal should resolve the said URI); 

• the fragmented of the ESG fragment that holds the auxiliary data. The fragmented is used to identify the 
auxiliary data fragment within an ESG fragment stream. 

The terminal can base its auxiliary data cache maintenance on the same method that is used to maintain its ESG XML 
fragment repository. When the terminal detects that a given ESG container has been updated, it can track the changes in 
fragment management information and check whether a particular ESG auxiliary data fragment has been updated, using 
the fragment_version and fragmented fields: 

• If a given fragmented has been removed from the received version of the ESG container, this means the 
corresponding file can be deleted from the cache. The corresponding URI might either not be valid anymore or 
in rare cases might have been assigned to another auxiliary data. 

• If a given fragmented has been added within the received version of the ESG container, this means a new 
ESG fragment is available. The terminal determines based on the esg_fragmenteype in the 
fragment_reference field if that ESG fragment is of type ESG auxiliary data. If this is the case the terminal 
caches the data accordingly. 

• If a new version of an ESG auxiliary data is available the cached auxiliary data that corresponds to the given 
fragmented is not valid anymore and can be updated with the new data. In that case the URI of the auxiliary 
data may change. 

Cached ESG auxiliary data might be accessed by an ESG Browser or other applications triggered by the ESG browser 
such as a HTML browser or image viewer. A conceptual model on how cached ESG auxiliary data can be accessed 
through a cache proxy is depicted in figure 7-3. The concept of a proxy such as the cache proxy is described for the case 
of a WebCastProxy in clause 6.4 of TS 102 591 [39]. If the triggered application requests information over the 
interactive channel the cache proxy would intercept the request in order to check for files corresponding to the required 
URL(s) within the delivered ESG containers via the ESG AUX Processing. In the case where the requested file(s) 
cannot be found in the cached ESG AUX Data, or in the ESG containers of the ESG fragment stream, the cache proxy 
may retrieve the files over the interactive channel. The latter assumes that the terminal is capable of data connection 
over an interactive channel. 

Cache management is application- specific, however it is expected that the application cache will discard ESG auxiliary 
data - e.g. web pages - that are no longer transmitted within the ESG fragment stream. 
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Figure 7-3: Conceptual model of a WEB browser aware of cached ESG auxiliary data 



7.5.3 Resolution of references to ESG auxiliary data 

ESG auxiliary data are resources which are referenced from an instance of the XML based data model e.g. an SDP file, 
an HTML page, an SVG file, a PNG file, etc. 

NOTE 1 : If HTML pages are transported as ESG Auxiliary data also the referenced entities from in the HTML 
page can also be interpreted as ESG Auxiliary data. Therefore the following is applicable to resolve the 
references to those entities. 

NOTE 2: Even though SDP files can be considered as ESG auxiliary data, it is possible to transport them within the 
ESG fragment stream or as files within a FLUTE Session. In both cases SDP files should be signalled 
using the MIME type "application/sdp". 

This ESG Auxiliary data may be delivered as part of the ESG fragment stream or may be available from the server side 
using the terminals interactive channel. 

The following describes how the terminal should resolve a reference to an ESG auxiliary data item. 

In the case where the URI defines one of the following schemes: 

• RTSP. 

The terminal should assume that the data is only available over the interactive channel. For all other schemes the 
following applies. 



In order to access a given ESG Auxiliary data referred to in a given ESG XML fragment, the expected 
terminal behaviour is as follows: 

If the ESG Auxiliary data is an SDP file, the ESG instance signals the FLUTE session that conveys the SDP 
file, when this latter is not inlined in an acquisition fragment: 

• Step l.a: The terminal listens to the declared FLUTE session and parses the FDT to locate and 
access the target SDP file within the FLUTE session. Note that the terminal may already be tuned 
to this FLUTE session. 

• Step l.b: If the SDP file is not signalled as a separate file in the declared FLUTE session, then the 
terminal has to search for the SDP file within the ESG fragment containers conveyed over the 
declared FLUTE session. ESG containers are signalled in the FDT by setting the attribute Content- 
Type="application/vnd.dvb.esgcontainer". 
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If the ESG Auxiliary data is not an SDP file: 

• Step 2. a: The terminal searches the ESG Auxiliary data within the ESG containers sent over the 
FLUTE session that transports the ESG XML fragment(s) that reference the ESG auxiliary data. 
Note that ESG auxiliary data are signalled within ESG containers according to clause 7.4.5 of 
TS 102 471 [1] 

• If the ESG auxiliary data is not found in the previous step, and if the ESG fragment stream 
is composed of multiple transport flows, then the terminal should try to locate the ESG 
auxiliary data in ESG containers conveyed in other transport flows that contribute to the 
ESG fragment stream. 

• Step 2.b: If the ESG auxiliary data is not found in step 2. a, the terminal has to consider the format 
of the URI of the ESG auxiliary data: if the URI of the auxiliary data is a point- to-point URL, then 
terminals having an interactive channel should resolve the given URL and access the signalled 
auxiliary data. 

• Typical URI schemes that are expected to be interpreted as point-to-point URLs are the "http", 
"rtsp", "mailto" schemes as described in RFC 1738 [24], RFC 2616 [16], RFC 2326 [25], 
RFC 2368 [26]. Note that it is expected that "http" and "rtsp" are commonly used for retrieving 
ESG Auxiliary data. 

Note that this order is only an example in this guideline document but implementations may differ to 
optimize the processing. 



Note that in the context of a point to point communication: 

• Depending on the protocol that is used, terminals may discover the characteristics of the given auxiliary data to 
fetch (e.g. mime type, codecs) and the associated delivery protocols (e.g. RTP transport features) only with 
server responses 

• It is beneficial that network servers provide ESG auxiliary data that can be consumed by terminals which 
comply with IPDC over DVB-H specifications (e.g. using A/V codecs defined in TS 102 005 [6], when 
appropriate). If the protocol that is used by the terminal to fetch the auxiliary data over the interactive channel 
supports the signalisation or negotiation of terminal capabilities, the network server may adapt the ESG 
auxiliary data accordingly. 

Terminals with an interactive channel are expected to implement the following protocols: 

• HTTPl.l (RFC 2616 [16]), RTSP (RFC 2326 [25]), RTP (RFC 3550 [35]). The use of RTSP and RTP are 
envisaged in the case where ESG auxiliary data is content streamed over a point to point communication. 

In case of a 3G point to point communication, terminals are expected to have e.g. 3GPP PSS or 3GPP2 MSS 
capabilities. 

Please see clause 8.4.3 for examples of how URIs may be used for the referencing of ESG auxiliary data. 

7.6 Processing of indexes 

Indexes may be used to optimize access to the set of fragments forming the ESG. In addition they may be used to: 

• Infer the set of ESG fragments that constitute the ESG at a given time. 

• Monitor for changes to the set of ESG fragments forming the ESG. 

The availability of indexes is announced to the terminal by setting the "IndexingFlag" within the ESG init message. 
This ESG init message is carried within the ESG init container which has a containerJD of "1". 

Also contained within the ESG init container is the index list structure, which signals the set of indexes provided with 
the ESG. The index list describes for each available index the set of fields that form the index and the encoding used to 
represent the index values. 
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Within TS 102 471 [1] only a single index (fragment index) is defined which is formed of the following fields: 

• IPFlowID; 

• fragmented; 

• fragment_version. 

Each index declared within the index list structure makes a reference to an index structure, which is typically carried 
within the same ESG container as that of the index list structure. The index structure specifies how the set of index 
entries are divided into one or more sub indexes, where each sub index is typically carried in a separate ESG container. 

How the index is split into multiple sub indexes is dependent on a number of factors: 

• The maximum size of an ESG container. 

• The frequency of updates to the indexed data. 

The index structure defines for each sub index the range of values that the sub index holds and the ESG container in 
which the sub index can be found. It is assumed that the sndex structure is fairly static in nature and will not change 
frequently during its lifetime. 

To detect changes to the set of ESG fragments forming the ESG, the terminal can monitor the index structure to detect 
changes to the set of sub index structures forming the index and their field ranges. These structures may or may not be 
carried in the same ESG container. Updates of the index structures can only be detected at the ESG container level by a 
change in the TOI of that ESG container. Because of this it is recommended that each sub index is carried within a 
dedicated ESG container. 

Once an updated ESG container has been acquired the terminal can compare the set of index entries with those of the 
previous version of the sub index. 

In the case that entries that are no longer present within the sub index and fall within the range of values of the sub 
indexes, the referenced fragments are assumed to have been deleted from the ESG. Entries which are new (fragmented 
not present in previous version), are assumed to be new fragments forming part of the ESG. Entries which have a new 
fragment_version to previous are assumed to have had their fragment contents updated. To update a terminals cache of 
ESG fragments the terminal may acquire the new fragment by acquiring the ESG container referenced by the index 
entry. 

7.7 Terminal behaviour on errors in the transmission of ESG 

The ESG application is assuming that the ESG containers received at the application layer are error free. In case of 
transmission errors, the loss of information may be avoided/reduced by the use of FECs which can be applied at the 
MPE layer or at the application layer within the ALC/LCT protocol as described in TS 102 472 [3]. However due to the 
fact that ESG acquisition should be enabled in a limited amount of time a configuration is often desirable which enables 
the delivery of the Transport Objects (TO) of the ESG FLUTE session available at that point in time, in a small number 
of DVB-H Bursts. Tests have shown that if MPE-FEC is used, the error characteristics are, that if errors are not 
corrected, it is likely that the complete DVB-H Burst is dropped (TR 102 377 [40]). Hence for the ESG configuration an 
application layer EEC on top of the MPE-FEC is not recommended. 

If an application layer EEC other than the No-Code EEC scheme is used the rules in clause 6.1.4 of TS 102 472 [3] 
apply, so decoders not familiar with that EEC scheme, can still consume the ESG. It should also be noted that neither in 
the ESG Access descriptor, nor in the ESG session partition declaration the signalling of other than the default EEC 
scheme is enabled. However if another EEC scheme is used the FDT and/or the EXT_FTI ALC/LCT header has to 
provide the corresponding signalling. 

Under the assumption that transmission errors result in dropped ESG containers the error pattern on the application 
layer are incomplete receptions of the ESG due to errors in the transmission. Such errors can be detected based on the 
FDT in the case where, FullFDT is signalled or based on missing ESG fragments which are indexed in the fragment 
index. 
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Based on the specification TS 102 471 [1] at least two strategies to react on the incomplete reception of ESG data are 
supported: 

• Wait for next transmission of the missed ESG containers. 

• In the case the missed ESG container is updated before it can be received (i.e. the TOI of that ESG container 
has changed) all updated ESG containers as e.g. listed in the full FDT instance have to be received in one of 
the following cycles of the FLUTE session. 

NOTE: Requesting ESG information over a bidirectional channel will be a subject of the phase 2 ESG specification. 

7.8 Processing of ESG data model instance 

In this clause a guideline is given on how to process an ESG data model instance. Two possible entry points into the 
data model instance are foreseen: 

• the service table - to navigate the announced services; 

• the schedule event table to browse the available content and/or services. 

7.8.1 Navigating through announced services 
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Figure 7-4: Relevant ESG XML fragments in tlie ESG data model and references between 
them to determine currently available services 

How to determine the list of services? 

The ServiceTable contains the Hst of service fragments that are currently described; however, this does not necessarily 
imply that the service is currently available, as a service could be temporally unavailable (e.g. between 3 a.m. and 
5 a.m. some TV services can be switched off). Each service is uniquely identified by the servicelD attribute forming 
part of the Service fragment. The servicelD is used to enable references from other ESG fragments, it is not intended to 
be displayed to the user. The ServiceName element holds the promotional name of the service, and the ServiceLogo 
holds a link to the logo that can be used to represent the service. The data model of the Service fragment also enables 
the assignment of a number to each service (through the ServiceNumber element); this number should be unique within 
the scope of the ESG. This information may be used to provide the user with the ability to directly select a service from 
the keypad, and to display the service list in an operator specific order. 
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How to know if a service is available? 



In order to check the availability of a given service at a particular time, the terminal can search for all schedule event 
fragments that reference a particular service (i.e. all schedule event fragments with ServiceRef element equal to the 
servicelD of the target service). Then if the PublishedStartTime and PublishedEndTime elements of one of these 
schedule event fragments match that particular time, the service is available. If the PublishedEndTime element is not 
instantiated it is identical to the PublishedStartTime of the subsequent schedule event of the described service assuming 
the schedule events are ordered in ascending order of PublishedStartTime (for more details on signalling schedule 
events see clause 5.2.3). In other words, the absence in the ESG of a schedule event fragment for a specific time interval 
should be interpreted as the unavailability of the service in this time interval. For detailed options of the ScheduleEvent 
fragment see clause 5.2.3. 

How to determine the content available on a service? 

The ScheduleEvent fragment may reference a content fragment (i.e. the value of the optional ContentFragmentRef 
element is equal to the value of the attribute ContentID of the Content fragment). In such case, the information from the 
content fragment can be displayed to the user. 

How to access a service? 

Each service may be linked to an acquisition fragment, which allows the tuning to the service through the use of an SDP 
file. This type of acquisition fragment is called "Service-related acquisition fragment". This is the default way to access 
a service. However, the terminal should also check to see if a temporary access method is available for the service at a 
particular time. This is described below. 

Note that in the case of a file download service (see use case in clause 6.5), the service-related acquisition fragment may 
not be sufficient to access the service. For instance in the case where particular content has to be located, the client 
should use the schedule event fragment that is related to the (service as described in the next clause) to access the 
service. 

A schedule event fragment that is linked to a service, may contain references to acquisition fragments, other than the 
service-related acquisition fragment referenced by the corresponding service, through the AcquisitionRef element. This 
type of acquisition fragment is called "schedule-related acquisition fragment". It is used typically to signal the 
temporary availability of additional options, for the acquisition of a particular event, such as additional language audio 
tracks. Note that in the case where the client is already accessing a service, using the service-related acquisition 
fragment, it is not required to consider a schedule-related acquisition fragment as soon as it becomes applicable. 
Schedule-related acquisition fragments are typically used when navigating through available content as described in the 
next clause. 

How to determine service access conditions? 

The actual access to a service depends on the rights associated to a service. A service may be free to air, or not, and 
possibly encrypted. This information can be directly found in the optional freeToAir and clearToAir boolean attributes, 
or can be deduced in the following way. 

The clearToAir attribute is used to indicate whether a service is encrypted or not. If the attribute is not present, the client 
terminal should look for the keyStream element in the acquisition fragment. If the keyStream element is present, the 
terminal should assume that the service is encrypted. If it is not present, the terminal should assume that the service is 
not encrypted, i.e. clear to air. 

The freeToAir attribute is used to indicate whether the content associated with the service is available for free or not. If 
the attribute is not present AND if the service is encrypted, then the client terminal should look for a purchase fragment 
related to the service. This is done by locating the purchase fragments that reference a service bundle fragment that the 
service is a member of (see below). If a purchase fragment with zero price attached exists, then the terminal should 
assume that the content is free to air, otherwise it should assume that it is not available for free. 
Note that if the service is not encrypted, it is assumed to be free to air, unless the attribute is explicitly set to false. 
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How to determine purchase information for a service? 
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Figure 7-5: Relevant ESG XML fragments in tlie ESG data model and references between 
them to determine purchase information of a particular services 

Purchase and access to a service depends on the previous step: 

• If the service is encrypted, the terminal should obtain the Traffic Encryption Key (TEK) [4] associated to the 
service from the key stream referenced in the KeyStream element in the acquisition fragment. Which key 
stream is appropriate for the terminal depends on the key management system in use and is signalled in the 
IPDCKMSId attribute of the KeyStream element. 

a) If the service is not available for free, the session key can be obtained by initiating the purchase of the 
service. In this case, the terminal should locate the service bundle fragments that reference this service, 
i.e. all service bundle fragments with ServiceRef element equal to the servicelD of the target service. 
Each service bundle is itself referenced from a purchase fragment by the serviceBundlelD. The terminal 
should locate the purchase fragment referencing a service bundle, display the purchase information to the 
user (such as usage constraints, price etc.) and initiate the actual purchase. The act of purchasing may 
require the use of information found within the purchase channel fragment referenced from the purchase 
fragment. 

b) If the service is available for free, the session key may already be available. It not, the session key can be 
retrieved as in the previous method, but by considering only the purchase fragment with price element 
equal to zero. 

• If the service is not encrypted, the terminal can directly access the service if it is free to air. 

Purchase and purchase channel fragments will typically contain private data (in PurchaseData or PrivateData elements). 
Private data elements in the ESG are supposed to be exposed to external applications. The client terminal should 
determine the target application using the namespace of the private data (given in the xsiitype attribute attached to the 
private data XML element). The default behaviour in case the namespace is not known by the ESG client application is 
to ignore the content of the private data element(s). 
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7.8.2 Navigating through available content/services 

How to determine the list of services available for a certain period of time? 
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Figure 7-6: Relevant ESG XML fragments in the ESG data model and references between them to 
determine services available in a particular period of time 

The ScheduleEventTable contains the list of schedule event fragments for all available events. The terminal can retrieve 
all schedule event fragments referencing available content in a given time frame through the PublishedStartTime and 
PublishedEndTime elements. It is recommended that these elements specify in UTC and to signal this explicitly by 
adding a "Z" to the dateTime string e.g. "2006-03-02T20:15:00Z". On the terminal side the UTC can be determined 
from the PSI/SI information within the DVB-H system. See TS 102 470 [5] and TS 102 591 [39] for details. 

In the case where the time is not given in UTC, but in a different time zone, the time shift different to UTC in the 
PublishedStartTime and PublishedEndTime elements should be formatted according to the dateTime datatype definition 
in XML Schema [18]. From the time shift information the terminal can determine the time based on UTC and thus map 
it to the time information available within the DVB-H system (TR 102 377 [40]). 

To easily determine the time period in which a schedule event is taking place it is recommended to instantiate 
PublishedEndTime. If this is not the case the terminal has to find the following ScheduleEvent fragment from the 
ScheduleEventTable which is related to the identified Service, to deduce the PublishedEndTime from the 
PublishedStartTime of that ScheduleEvent. 

A schedule event fragment references a particular service through the ServiceRef element. For a given service, the 
presence of a schedule event fragment in a specific time interval that references the service should be interpreted, as the 
availability of the service in that time interval. From this schedule event fragment, the terminal can locate in a 1st step 
the corresponding Service fragment and in a 2"^ step the acquisition(s) fragment(s) enabling access to the service. 

Beside evaluating if a particular service is available based on the schedule events related to that service, the terminal 
may be required to evaluate if it has the rights to consume the service. I.e. the terminal evaluates if there is a 
ServiceBundle containing that service for which the terminal has the right to access and consume. 

NOTE 1: The times declared within the ESG fragments, only define published times, and so it is not recommended 
to use these values to control acquisition. These published times are declared in UTC where the current 
time can be inferred from the TDT available within the transport stream carrying the ESG service. In 
addition there is a sampling clock carried within an RTP stream, which is used by the player to perform 
playout of the content. This clock is independent to that used within the ESG. 

NOTE 2: The IPDC ESG specification [1] as well as this guideline do not specify or recommend how the UTC is 
mapped to the local time of the terminal, and in which time zone the information is shown to the user, as 
this is seen to be a terminal implementation issue. 
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How to determine the list of available content for a certain period of time? 
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Figure 7-7: Relevant ESG XML fragments in the ESG data model and references between them to 
determine content available in a particular period of time 

The determination of available services and schedule events related to them has been described above, schedule event 
fragments usually hold a reference to a content fragment, which describes the content item available in this event, 
through the ContentFragmentRef element. From the available services the available content can then be determined 
based on the ContentFragmentRef element in the ScheduleEvent fragment. 

NOTE 3: If schedule event fragments are only used to signal service availability in a certain period of time they do 
not contain a ContentFragmentRef element. 

How to access the available content (s)? 
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Figure 7-8: Relevant ESG XML fragments in the ESG data model to determine 
and to access available content 

The terminal should access the content using the Schedule-related acquisition fragment attached to the schedule event 
fragment that references this content fragment as described earlier. 

If there is no Schedule-related acquisition fragment, the terminal should locate the service fragment related to the 
available content in a P^ step and then should access the content through the service-related acquisition fragment. 

NOTE: In case a given session is described in both Service-related acquisition fragment, and Schedule-related 
acquisition fragment, the terminal is not expected to automatically load the Schedule-related acquisition 
fragments SDP, when it becomes valid (i.e. when the particular time is between PublishedStartTime and 
PublishedEndTime of the associated schedule event fragment). 
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How to access individual contents in a file download service? 

In the case of a file download service, there are 3 cases to consider according to the structure of the ScheduleEvent 
fragment: 

• If the ScheduleEvent fragment contains only one ContentFragmentRef element, and no ContentLocation 
element, it means that the content associated to the download service is formed of all the files, that are 
transmitted in the FLUTE session that carries this service. The terminal should locate the schedule-related 
acquisition fragment (or, if not available, the service-related acquisition fragment) in order to access the file 
download FLUTE session. 



< ScheduleEvent > 

<PublishedStartTime>2006-03-02T20 : 15 : 00</PublishedStartTime> 
<PublishedEndTime>2006-03-02T21 : 00 : 0</PublishedEndTime> 
<ServiceRef IDRef ="dvbipdc : //example . com/Channell"/> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/RingTones"/> 
</ ScheduleEvent > 



If the ScheduleEvent fragment contains one pair of ContentFragmentRef and ContentLocation elements, it means that 
the described content is formed of only one file. The ContentLocation element provides the URI of the file in the 
download FLUTE session that is described in the acquisition fragment. 



< ScheduleEvent > 

<PublishedStartTime>2006-03-02T20 : 15 : 00</PublishedStartTime> 
<PublishedEndTime>2006-03-02T21 : 00 : 0</PublishedEndTime> 
<ServiceRef IDRef ="dvbipdc : //example . com/Channell"/> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/RingTonelOO"/> 
<ContentLocation>http: //example . com/RingTonelOO .mp3</ContentLocation> 

< /ScheduleEvent > 



If the ScheduleEvent fragment contains multiple ContentFragmentRef elements, it means that the described content is 
formed of multiple files. The terminal can obtain the files independently, using the ContentLocation elements. 



< ScheduleEvent > 

<PublishedStartTime>2006-03-02T20 : 15 : 00</PublishedStartTime> 
<PublishedEndTime>2006-03-02T21 : 00 : 0</PublishedEndTime> 
<ServiceRef IDRef ="dvbipdc : //example . com/Channell"/> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/RingTonelOO"/> 
<ContentLocation>http: //example . com/RingTonelOO .mp3</ContentLocation> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/RingTonel"/> 
<ContentLocation>http: //example . com/RingTonel .mp3</ContentLocation> 
<ContentFragmentRef IDRef ="dvbipdc : //example . com/RingTone2 "/> 
<ContentLocation>http: //example . com/RingTone2 .mp3</ContentLocation> 

< /ScheduleEvent > 



NOTE: The ContentLocation element is of type anyURI. So also URLs such as 

http://example.com/RingTone2.mp3 would be a correct URI which identifies content in a FLUTE session 
based on the content location listed in the FDT of that FLUTE session. 

7.9 Initialisation information for service consuming application 

Details of information obtained from the ESG datamodel for initialisation of service consuming applications are given 
in the clauses 5 and 6 in TS 102 591 [39]. 
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8 ESG delivery guidelines 



In this clause, the ESG deHvery is discussed. This clause provides first guidelines on ways in which terminals can be 
expected to discover the different ESGs that are available within a given IP platform. Then, the transport of the ESG is 
described. Thirdly, guidelines for the encapsulation of the ESG fragments are proposed. Finally, recommendations on 
server side processing are given. 



8.1 ESG bootstrap session 



The ESG bootstrap is the mechanism through which the terminal discovers, which ESGs are available, and how to 
acquire them, in the scope of a given IP platform. Considering the services accessible over the broadcast channel, these 
ESGs are limited to only describe those services accessible in the given IP platform. For each IP platform for which 
theres at least one ESG service declared, a FLUTE delivery session is used to deliver the ESG bootstrap information to 
the terminals. 

The well-known destination IP address (224.0.23.14 defined for IP version 4 and FF0X:0:0:0:0:0:0:12D for IP version 6 
format) and the port 9214, for this ESG bootstrap session, are registered at lANA; see [13], [14], [15] for respective 
multicast addresses and port assignments. Furthermore, this session is the only one sent to that destination address and 
port, therefore the terminal does not require any additional information e.g. TSI of the session to start the bootstrap 
process. 

As defined in clause 5.1 of TS 102 470 [5], within one IP platform, only one IP version SHOULD be used. However, if, 
within a given IP platform, IP version 4 as well as IP version 6 are used, the following guidelines have to be considered. 

Regarding the ESG transport and the ESG datamodel instantiation, the use of IP addresses is limited to three places: 

a) the ESGEntries in the ESGAccessDescriptor in the ESG Bootstrap Session; 

b) the ESG session partition declaration; 

c) SDP files both inlined or referenced from the acquisition fragments. 

For a) ESGEntries and b) ESG session partition declaration, the use of IPv4 as well as IPv6 in a given instance is not 
supported. 

For c) SDP files, it is not recommended to mix IP versions in the same SDP according to TS 102 591 [39], 
clause 5.1.1.2. The only exception being the "o=" field since e.g. an IPv4 host can generate an SDP for IPv6 sessions. It 
is recommended that the ESG is containing, or referencing only SDP files according to TS 102 591 [39], clause 5.1.1.2 
with source and destination IP addresses of one IP version, which is the one used for the transport of the ESG itself. 

It is recommended that the bootstrap session contains an ESGAccessDescriptor which holds ESGEntries using the same 
IP version as used for the transport of the bootstrap session itself. 

At a given time on a given IP platform, there is only one ESG delivered by an ESG provider for a given IP version. 

Per bootstrap session, it is assumed that there is only ever one ESGProviderDiscovery descriptor and one 
ESGAccessDescriptor for IPDC ESGs, and each is sent as a separate file. However, it should be noted that nothing 
prevents several ESGAccessDescriptors to be available on a given bootstrap session when ESG(s) of different type(s) 
are advertised. 

The ESGProviderDiscovery descriptor is an XML file whose aim is to inform terminals and users about the various 
ESG providers that deliver ESGs in a given IP platform. It provides a textual description of the ESG providers, allowing 
the user to easily select one of the ESGs. This file is expected to be carouselled at a low rate (e.g. each 10 s). 

The ProviderURI element specifies a URI uniquely identifying the ESG provider. This field may be used by terminals 
or users as an entry point to discover the declaration of a particular ESG. It's therefore recommended that the 
ProviderURI values are unambiguously understood by terminals or users. A reliable way is to use, in the ProviderURI 
field, the Internet DNS domain name, registered by the ESG provider. 
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There is no assumption on the fact that the ProviderName field provides a unique identifier of a given ESG provider.In 
the scope of a given IP platform, a ProviderlD's numeric value is assigned by the entity that manages the bootstrap 
channel to uniquely identify each ESG provider. A particular ESG provider may be assigned one given ProviderlD 
value in a scope of a given IP platform and a different ProviderlD value in a scope of a different IP platform. Within a 
given IP platform, it's possible to re-use a particular ProviderlD value, provided that sufficient time has elapsed since 
this ProviderlD value was last used. If ESG provider logo files are referenced from the ProviderLogo element in the 
ESGProviderDiscovery descriptor file, and if they are sent over the broadcast channel, it is recommended that the ESG 
provider logo files are transmitted in the ESG bootstrap session. If the logo files are not transmitted within the ESG 
bootstrap session, the terminal should assume that the logos are available over the interactive channel if the URI is an 
URL. The following is an example of an ESGProviderDiscovery descriptor XML instance, declaring two different 
ESGs (from two different ESG providers): 



< ESGProviderDiscovery xmlns="urn:dvb : ipdc resgbs : 2 005" xmlns :mpeg7="urn:mpeg:mpeg7 : schema: 2 001" 
xmlns :xsi="http: //www. w3 . org/2 l/XMLSchema- instance" > 
<ServiceProvider> 

<ProviderURI>mycompanyl . example . com</ProviderURl> 
< ProviderName >mycompany 1 < /ProviderName > 

< ProviderLogo 

<mpeg7 : Titlelmage> 

<mpeg7 :MediaUri>mycompanyllogo . jpg</mpeg7 :MediaUri> 
</mpeg7 : Titlelmage> 
< /ProviderLogo 
<ProviderlD>l</ProviderlD> 

<ProviderlnformationURL>http: //www.mycompanyl .example . com/about .php</ProviderInformat 
ionURL> 
</ServiceProvider> 
<ServiceProvider> 

<ProviderURI>mycompany2 .example . com</ProviderURI> 
< ProviderName >mycompany2</ ProviderName > 

< ProviderLogo 

<mpeg7 : Titlelmage> 

<mpeg7 :MediaUri>mycompany21ogo . jpg</mpeg7 :MediaUri> 
</mpeg7 : Titlelmage> 
< /ProviderLogo 
< ProviderlD >2</ ProviderlD > 

<ProviderInformationURL>http: //www. my company 2 .example . com/about .php</ProviderInformat 
ionURL> 
</ServiceProvider> 
< /ESGProviderDiscovery > 



Once a user has selected an ESG ServiceProvider, the ProviderlD element is used by the terminal to select the 
appropriate entry within the ESGAccessDescriptor. This provides information on how to acquire the ESG announced by 
the selected ESG provider. The ESGAccessDescriptor is encoded in a binary format in order to reduce both bandwidth 
and terminal processing time. It is intended to be carouselled at a high rate (e.g. at least once a second). 

For a given ESGEntry, the Multiples treamTransport field may be: 



• 



Set to "1", to indicate that the ESG is transported over multiple transport flows. Then the SourcelP Address, 
DestinationIP Address, port, and TSI that are associated to this ESGEntry, describes the FLUTE session of the 
announcement carousel. 

• Set to "0" to indicate that the ESG is delivered over one transport flow, where the SourcelP Address, 

DestinationIP Address, port, and TSI that are associated to this ESGEntry, describes the FLUTE session on 
which the ESG is delivered. 

Reserved bits shall be set to "1" according to TS 102 471 [1]. 

Table 8-1 is an example of a ESGAccessDescriptor file, describing first an ESG (from one ESG provider) that is 
transported using multiple transport flows, and second, an ESG (from a second ESG provider) that is transported using 
one transport flow. 
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Table 8-1 : Example of an ESGAccessDescriptor 



Field 


Hex Value 


Field Length 
(bits) 


Mnemonic 


Description 


Decimal value 


n_o_ESG Entries 


0x0002 
2 


16 


uimsbf 


number of ESGEntries 


ESGEntryVersion 


0x01 

1 


8 


uimsbf 


version of the ESG 
entry specification. 


ESGEntryLength 


0x0 F 
15 


8 


vluimsbf8 


length of the 
ESGEntry in Bytes. 


MultipleStreamTransport 


OxBF 


1 


bslbf 


if set to "1" specifies 
that a FLUTE session 
is described which 
transports an 
announcement 
carousel session. 


IPVersion6 


1 


bslbf 


if set to "1" specifies 
that the 

SourcelPAddress and 
the 

DestinationlPAddress 
are signalled 
according to IP version 
6. 


Reserved 


6 


bslbf 




ProviderlD 


0x0001 

1 


16 


uimsbf 


identifies uniquely the 
ESG provider. 


SourcelPAddress 


0X0A06620E 
"10.6.98.14" 


32 


bslbf 


source IP address of 
the transport flow 
transporting the ESG. 


DestinationlPAddress 


OxEIOOOOSB 
"225.0.0.59" 


32 


bslbf 


destination IP address 
of the transport flow 
transporting the ESG. 


Port 


0x1970 
6512 


16 


uimsbf 


port number of the 
transport flow 
transporting the ESG. 


TSI 


0x0001 

1 


16 


uimsbf 


transport Session 
Identifier (TSI) of the 
transport flow 
transporting the ESG. 


ESGEntryVersion 


0x01 

1 


8 


uimsbf 


version of the ESG 
Entry Specification. 


ESGEntryLength 


0x0 F 
15 


8 


vluimsbf8 


length of the 
ESGEntry in Bytes. 


MultipleStreamTransport 


0x3F 


1 


bslbf 


if set to "1" specifies 
that a FLUTE session 
is described which 
transports an 
announcement 
carousel session. 


IPVersione 




1 


bslbf 


if set to "1" specifies 
that the 

SourcelPAddress and 
the 

DestinationlPAddress 
are signalled 
according to IP version 
6. 


Reserved 




6 


bslbf 




ProviderlD 


0x0002 
2 


16 


uimsbf 


identifies uniquely the 
ESG provider. 


SourcelPAddress 


0X0A06620F 
10.6.98.15 


32 


bslbf 


source IP address of 
the transport flow 
transporting the ESG. 


DestinationlPAddress 


OxEIOOOOSC 
225.0.0.60 


32 


bslbf 


destination IP address 
of the transport flow 
transporting the ESG. 
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Field 


Hex Value 


Field Length 
(bits) 


Mnemonic 


Description 


Decimal value 


Port 


0x1 96F 
6511 


16 


uimsbf 


port number of the 
transport flow 
transporting the ESG. 


TSI 


0x0001 

1 


16 


uimsbf 


Transport Session 
Identifier (TSI) of the 
transport flow 
transporting the ESG. 



Note that the structure of the ESGAccessDescriptor file provides means to add fields in a forward compatible way. 



8.2 ESG transport 



Over the broadcast channel, the ESG data (e.g. ESG XML fragments, auxiliary data) is delivered using ESG containers, 
with the possible exception of SDP files that can alternatively be transported as separate files, as described in 
clause 5.1.1.1.1 of TS 102 591 [39]. 

ESG containers can be transported in two different ways: 

• the "single stream mode", where ESG containers are transported as Transport Objects (TO) in a single FLUTE 
session; and 

• the "multiple stream mode", where ESG containers are transported in multiple FLUTE sessions which are 
distributed over several transport flows. 

A fragment indexing structure (see clause 8.2.2.2) can be used to enable a terminal to track changes to fragments 
without having to acquire all the ESG containers within an ESG delivery session. 

In the multiple stream case, the ESG data are split into a number of separate transport flows. A partitioning strategy 
determines the set of data to be carried in each transport flow. The ESG session partition declaration tells the terminal, 
how the ESG is partitioned, and what the partitioning criteria for each session are. 

Possible goals for a containerisation and partitioning strategy 

The choice of which ESG fragments are put into the various ESG containers and in the multiple- stream case, which 
ESG fragments are transported by which flow should be made, in order to meet the following goals: 

• In the multiple stream mode, the terminal should be required to open as few sessions as possible in order to 
acquire the particular subset of ESG data of interest. 

• The terminal should be required to process as few ESG containers as possible in order to acquire ESG data of 
interest (e.g. updated fragments or referenced fragments). 
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8.2.1 Single stream case 

In the single stream case, the ESG containers are carried in a single FLUTE session as illustrated in figure 8-1. 



Fixed ESG 
Bootstrap Session 
DescriploF---,^ 



MultipleStreamTransport = 



I 224.0.23.14:9214 | 





TOI = 




full FDT Instance 










-► 


TOI = N 


ESGProviderDis- 
covery Descriptor 






^ 


TOI = M 


ESGAccess 
Descriptor 




' 



ESG Bootstrap FLUTE Session 




Container_ID, Version 
Information for each container 



Init Container 

one ESG Init Message 
an optional ESGMain Fragment 
an optional Index List Structure and 
an optional Index Structure 



representation of the ESG, the presence 
of an index and the Decoderlnit 

list of all indices that exist for 
the entire metadata fragment 
stream. 



global settings for the Index, 
declare the set of sub indexes that 
make up the index 
declare range of values that can 
be found within a given sub index. 

Fragment Index 



initial description of the ESG 
Document 



MF Subldxmay be in 
another container 



Index Containers - Containers carrying Indexing 
information, and holding the following structures: 

multi_field_sub_index, 

data_repository 



Fragment Index 



Fragment Ref, ID, Version 



ESG Fragments 



Fragment Ref, ID, Version 
ESG Fragments 



Figure 8-1 : ESG container delivery in the case of single stream transport 
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In figure 8-1, an FDT instance with the FullFDT attribute equals to true is called Full FDT instance. The FullFDT 
attribute set to true indicates to the terminals that the FDT instance signals the exact set of Transport Objects (TO) that 
are currently scheduled for transmission by the sender, in the FLUTE session. It's recommended to use this attribute so 
that terminals detect that the received ESG instance is consistent at a given time. 

8.2.1 .1 ESG container updates 

Container_ID and versioning information, conveyed by the transport layer are used to enable a terminal to track 
changes to ESG containers. 

The default and mandatory way to announce new versions of a ESG container is to provide an FDT instance with a new 
FDT instance ID as specified in the clause 8 of TS 102 471 [1]. The new FDT instance declares a new mapping of the 
ESG container's "Content-Location" field to a new TOI value. 

An optional way is to use the Split TOI mechanism. It conveys the ESG containers versionJD as part of the ESG 
containers associated TOI value. This allows the terminal to keep track of changes in ESG container versions directly at 
the transport level, without the indirection of the FDT. This mechanism can be signalled in the FDT by the Version-ID- 
Length attribute as specified in clause 8.1.3 of TS 102 471 [1]. 

For more details on ESG container updates and version information see clause 8.3. 

8.2.1 .2 Indexing and fragment updates 

The fragment indexing structure can be used to enable a terminal to track changes to fragments without having to 
acquire all the ESG containers within an ESG session. 

This structure comprises an index list, index and in the single-stream case, one sub index. 

In the single-stream case, these structures are carried on the same transport flow as the ESG fragment containers. 
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index list 



index_descriptor_length 



fragment_type 



if(fragment_type == Oxffff) 



field identifier 



ath ntr 



n^iiciu_iuciiiiiier — Oxffff) 



|field_xpatli_ptr 



field_encoding 



num fields 



index container 



index identifier 



num indexes 



overlapping_subindexes 



single_layer_sub_index 



fragment_locator_format 



if (overlapping_subindices == '1' ) 



low field value 



high_field_value 



num fields 



sub index container 



sub index identifier 



num sub indexes 



multi field sub index 



multi field header 



single. 



leaf field 



multiplejocators 



layer_sub_index_structure 



multi field index entries 



num fields 



IPFIowlD 



fragment Id 



fragment version 



Set to 0x00 

(i.e. Index is not limited to a 

particular ESG XML Fragment type 

J 



field_identifier 

0x0001 (IPFIowlD) 
0x0002 (fragmentjd) 
(unsigned long) 
0x0003 (fragment_version) 



field_encoding 

0x0206 (unsigned Byte) 
0x0201 

0x0101 (unsigned short) 



Identifies the Container ID and 
the Structure ID of the Structure 
which holds the index 




Set to 



Set to 1 



SettoOxEl 
(container_fragment_ 
locator is Container ID 



Identifies the Container ID and 
the Structure ID of the Structure 
which holds the sub index 



container_fragment_locator 

[ContainerJD 



Set to 0x00, single stream case 



Single stream case: indexing structure in the same Transport flow as the ESG fragment containers 

Figure 8-2: Index instantiation in the case of single stream transport 

The index_list structure announces the index structure, which in turn announces the single Multi-field sub-index. By 
monitoring the fragment_id and fragment_version fields in the Multi-field sub-index, the terminal can detect fragment 
updates. 

8.2.1 .3 Strategy for grouping fragments into ESG containers 

As soon as a fragment is updated within an ESG container, the ESG container version is updated. In this case the 
terminal might need to reload the ESG container to get the updated fragment. It is reasonable to consider that separating 
static fragments and dynamic fragments can potentially reduce the number of ESG container updates by grouping 
potential fragment updates in the same ESG container(s). Thus this could reduce the number of ESG containers a 
terminal must acquire to get the updated fragments. 
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This strategy can be combined with the grouping of related fragments. 



To achieve this some general guidelines are: 



Group fragments that are considered dynamic and fragments that are considered static in different 
ESG containers. The following classification seems to be appropriate in most cases: 

o ESG container updates can be minimized by using the same ESG containers to carry 

relatively static service fragments and purchase channel fragments. 
o Another group of fragments having similar dynamics, consisting of acquisition fragments 

and encapsulated SDP files, these can also be put into common ESG containers. 
o A third natural group consisting of content fragments and schedule fragments. 
o A fourth pair of fragments are purchase fragments and ServiceBundle fragments which also 
have similar dynamics. 
A service fragment and related acquisition fragment(s) can be grouped in the same ESG container, so 
that in a cold start situation, the terminal can start to play the service immediately without having to 
wait for the entire ESG to be loaded. Remember that the order in which ESG containers are received 
is random, and therefore the service processing order is non deterministic, too. 
The SDP information for service-related acquisition fragments can be inlined in service-related 
acquisition fragments, which again helps the terminal to start to play a service quickly. However this 
solution has a drawback: if there are changes in the SDP(s), they are reflected as changes also in the 
ESG. However the changes might not been tracked by terminals which are not consuming the ESG in 
parallel to the service(s) to which they are tuned. 
If an SDP file is not inlined: 

o The SDP file can be delivered as an ESG auxiliary data as specified in clause 7.4.5 of 

TS 102 471 [1]. This option allows as fast a channel change time as that of inlined SDP. In 
this case any SDP file can be carried in dedicated ESG container(s), thus allowing SDP files 
on the server side to be provided separately by the network operator or to be stored en block 
in the terminal for quick access. 
o The SDP files can also be delivered in a FLUTE session without containerization in the same 
DVB-H Bursts as the media. This enables the terminal to update SDP files in parallel to the 
media session consumption. However, for acquisition starting from the ESG, this requires a 
terminal to get the related DVB-H Bursts, to receive the data from the FLUTE session 
transporting the SDP file, and then initializing the player based on the SDP file. 
Group time-related schedule event fragments and their associated content fragments in the same ESG 
containers; however, the maximal size of a given ESG fragment container should be taken into 
account. 



NOTE 1 : A fragment can be considered as dynamic if it is expected to be updated frequently. For instance schedule 
event fragments and their related content fragments are dynamic by nature: their lifetimes are limited. 
A fragment can be considered as static if it is rarely updated. For instance service fragments are static by 
nature: a service description is rarely updated. 

NOTE 2: The static and dynamic notions are related to the ESG context described. In some cases content fragments 
can be considered as static: e.g. if the same programs descriptions are repeated every day; in this case the 
schedule event fragments are dynamic but not their related content fragments. 

NOTE 3: If a cycle of the ESG is contained in more than one DVB-H Burst and if terminals that are addressed start 
rendering on partial reception of ESGs, it could be beneficial that ESG providers adapt the carousel rate 
of each ESG container, depending on the nature of the ESG fragments that are transported. For example, 
a ESG container carrying schedule event fragments and their associated content fragments relating to the 
present programme schedule time and the immediate future could be carouselled at a higher cycle rate 
than a ESG container carrying schedule event fragments and their associated content fragments describing 
programs happening next week. 

NOTE 4: The maximum size of an ESG fragment container is limited to the value that can be expressed by the 
24 bit field of esg_data_repository_offset according to clause 7.3.3 in TS 102 471 [1]. 
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8.2.2 Multiple stream case 



In the multiple stream case, the ESG is carried in several FLUTE sessions similar to those illustrated in figure 8-3. 
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Figure 8-3: ESG container delivery in the case of multiple stream transport 
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The optional indexing structure is carried in the announcement carousel, intended to be repeated at a rate high enough to 
be carried in each DVB-H Burst carrying ESG data. 

It is recommended that an FDT instance holds a "FullFDT" attribute set to "true" in the ESG Announcement FLUTE 
Aession. If an index is present in the ESG Announcement FLUTE Session, the terminal can assume that the set of ESG 
fragments listed by the index carried in the ESG Announcement FLUTE Aession, is consistent. 

The sessions that are declared in the ESG session partition declaration can be carouselled at rates which depend on how 
important the set of ESG data they carry may seem to a typical user, and on the number of users expected to make use 
of these data. 

NOTE: Further specification work will address the delivery of the ESG data over the interactive channel in order 
to e.g. possibly dedicate the broadcast delivery mode to only ESG data that are of interest to a large 
number of users. 

8.2.2.1 ESG container updates 

The same rules apply as for the single stream case described in clause 8.2.1.1. 

8.2.2.2 Indexing and fragment Updates 

The diagram below depicts the index structure separated into multiple sub indexes. Considering the multi-stream mode 
ESG delivery, this division point is based on the transport flow and each Sublndex will have all entries for one transport 
flow. The declaration of only one sub index per transport flow helps the terminal to monitor updates in this transport 
flow. Moreover, a given ESG container should not contain sub indexes representing different transport flows. If there 
are several sub indexes representing the same transport flow, they should be placed into the same ESG container taking 
the ESG container size and the update frequency of sub indexes under account. 
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Multi-Stream case: indexing structure in tine Announcement Carousel 

Figure 8-4: Index instantiation in the case of multiple stream transport 

NOTE: The field IPFIowlD in the index identifies the transport flows declared in the ESG session partition 
declaration. 

In the following, an example of an index is given. For details of the field definitions, see clause 8.2.1 of TS 102 471 [1] 
and clause 4.8.5.3 of TS 102 822-3-2 [21]. 

The keying is based on the triplet "{IPFIowlD, fragment_id, fragment_version}" where the key is declared using three 
{field_identifier, field_encoding} pairs where the field_identifier declares the semantics of the field in the key and the 
latter declares the format/encoding of the field to be used in the "sub_index" when the key is instantiated. 
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Example instantiation of index List Structure 



Table 8-2: Example of an index list structure 



Field 


Hex value 


Field 
length 
(bits) 


Mnemonic 


Description 


Decimal 
value 


index_descriptor_length 


0x12 
18 


8 


uimsbf 


length of this structure excluding this length 
field (18 bytes). Based on the length the 
amount of the indexes listed in the index 
List can be inferred. 


fragmenMype 


0x0000 



16 


uimsbf 


0x0000 meaning any fragment type. Fixed 
value as specified in TS 102 471 [1]. 


numjields 


0x03 
3 


8 


uimsbf 


0x03 meaning key consisting of three fields 
as specified in TS 102 471 [1]. 


fieldjdentifier 


0x0001 

1 


16 


uimsbf 


0x0001 meaning transport flow identifier. 


field_encoding 


0x0206 


16 


uimsbf 


0x0206 meaning 8 bit unsigned integer. 


field identifier 


0x0002 


16 


uimsbf 


0x0002 meaning fragment identifier. 


field encoding 


0x0201 


16 


uimsbf 


0x0201 meaning unsigned long (32 bit). 


field identifier 


0x0003 


16 


uimsbf 


0x0003 meaning fragment version. 


field encoding 


0x0101 


16 


uimsbf 


0x0101 meaning unsigned short (16 bit). 


index_container 


OxBABE 
47806 


16 


uimsbf 


OxBABE meaning the numeric identifier of 
the ESG container containing the "index" 
itself. Note that "OxBABE" is just an 
example value. 


indexjdentifier 


OxCE 
206 


8 


uimsbf 


OxCE meaning the identifier of the 
structure representing the index. In this 
example the index is located in the 
structure "OxCE" in the ESG container 
"OxBABE". Note that there may be more 
than one structure in one ESG container 
having the same identifier. In such a case 
the structures are further identified based 
on their type. 



NOTE: To stay compatible with the index defined in TS 102 822-3-2 [21], clause 8.2.1.6 (index list structure 
instantiation) of TS 102 471 [1] reuses already defined field encodings. Thus the fragment version is 
instantiated using a 16 bit unsigned integer, although in clause 7.3.1 (ESG fragment management 
information) of TS 102 471 [1] the fragment_version is represented using 8 bits (only the 8 less 
significant bits will be actually used in the related field_identifier). The same applies for fragment 
identifier that uses here 32 bits however only the 24 least significant bits are actually used. 

See TS 102 471 [1] clause 3.2 for field encoding mnemonics. 

Example of the index Structure 

The index declares the "sub indexes", each of which in turn declares the fragments being delivered in one transport 
flow. 

See clause 4.8.5.4 of TS 102 822-3-2 [21] and clause 8.2.1 (IPDC index Specification) of TS 102 471 [1] for more 
information. 

TS 102 471 [1] defines the following restrictions for sub indexes: 

• Clause 8.2.1.2 (index structure) says that the "overlapping_subindex flag is not supported". 

• Clause 8.2.1.3 (sub index structure) says that "only single_layer_sub_index is allowed. Use of 
multi_layer_sub_index is not supported" . 
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The example below declares "sub indexes" for transport flows with identifiers "OxAC", "OxBC" and "OxBF". Recall that 
these transport flows are signalled in the "ESG session partition declaration". The association of the transport flows with 
the "sub indexes" is as follows: 

Table 8-3: Example of a sub index configuration for a particular multiple transport case 



Transport Flow (hex 
and decimal value) 


ESG container (hex and 
decimal value) 


Structure 


OxAC 
172 


OxCAFE 
51966 


0x01 


OxBC 
188 


OxCAFF 
51967 


0x01 


OxBF 
191 


OxDOOO 
53248 


0x06 



Table 8-4 is an example instantiation of index structure. 



Table 8-4: Example of an index structure in the case 
of a particular multiple stream transport configuration 



Field 


Hex stream 


Field 

Length 

(bits) 


Mnemonic 


Description 


Decimal 
value 


overlapping_subindexes 


"0" 


1 


bslbf 


always set to zero indicating that the "sub index" 
structures are mutually non-overlapping, i.e. that 
no two "sub index" structures may declare the 
same fragment. See "8.2.1 .7" of TS 1 02 471 [1]. 


single layer sub index 


"1" 


1 


bslbf 


always set to one. See "8.2.1 .7" of TS 1 02 471 [1 ]. 


reserved 


"111111" 


6 


bslbf 


always set to "1"s. 


fragmentjocatorjormat 


OxEl 


8 


uismbf 


always set to OxEl . See "8.2.1 .7" of TS 1 02 471 
Ml. 


high_field_value 


OxAC 
172 


8 


uismbf 


set to the transport flow identifier (declared in the 
"ESG session partition declaration") of the session 
carrying the fragments referenced by the "sub 
index" introduced here. The value "OxAC" is just an 
example. 


high_field_value 


OxOOFFFFFF 
16///215 


32 


uismbf 
See note 1 


the greatest fragment identifier value it may be 
possible to find in the transport flow "OxAC". See 
Note 3. 


high_field_value 


OxOOFF 
255 


16 


uismbf 
See note 2 


the greatest fragment version value it may be 
possible to find in the transport flow "OxAC". See 
Note 4. 


sub_index_container 


OxCAFE 
51966 


16 


uismbf 


the identifier of the ESG container holding the "sub 
index" declaring the fragments transported in the 
transport flow identified by value "OxAC". 


subjndexjdentifier 


0x01 


8 


uismbf 


the identifier of the "sub index" structure in the 
ESG container "OxCAFE" declaring the fragments 
transported in the transport flow identified by value 
"OxAC". 


high_field_value 


OxBC 
188 


8 


uismbf 


set to the transport flow identifier (declared in the 
"ESG session partition declaration") of the session 
carrying the fragments referenced by the "sub 
index" introduced here. The value "OxBC" is just an 
example. 


high_field_value 


OxOOFFFFFF 
16777215 


32 


uismbf 
See note 1 


the greatest fragment identifier value it may be 
possible to find in the transport flow "OxBC". See 
Note 3. 


high_field_value 


OxOOFF 
255 


16 


uismbf 
See note 2 


the greatest fragment version value it may be 
possible to find in the transport flow "OxBC". See 
Note 4. 


sub_index_container 


OxCAFF 
51967 


16 


uismbf 


the identifier of the ESG container holding the "sub 
index" declaring the fragments transported in the 
transport flow identified by value "OxBC". 
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Field 


Hex stream 


Field 

Length 

(bits) 


Mnemonic 


Description 


Decimal 
value 


subjndexjdentifier 


0x01 


8 


uismbf 


the identifier of the "sub index" structure in the 
ESQ container "OxCAFF" declaring the fragments 
transported in the transport flow identified by value 
"OxBC". 


high_field_value 


OxBF 
191 


8 


uismbf 


set to the transport flow identifier (declared in the 
"ESQ session partition declaration") of the session 
carrying the fragments referenced by the "sub 
index" introduced here. The value "OxBF" is just an 
example. 


high_field_value 


OxOOFFFFFF 
16///215 


32 


uismbf 
See note 1 


the greatest fragment identifier value it may be 
possible to find in the transport flow "OxBF". See 
Note 3. 


high_field_value 


OxOOFF 
255 


16 


uismbf 
See note 2 


the greatest fragment version value it may be 
possible to find in the transport flow "OxBF". See 
Note 4. 


sub_index_container 


OxDOOO 
53248 


16 


uismbf 


the identifier of the ESQ container holding the "sub 
index" declaring the fragments transported in the 
transport flow identified by value "OxBF". 


subjndexjdentifier 


0x01 


8 


uismbf 


the identifier of the "sub index" structure in the 
ESQ container "OxDOOO" declaring the fragments 
transported in the transport flow identified by value 
"OxBF". 


NOTE 1 : The encoding of the fragment identifier is a 24-bit unsigned integer as specified in TS 102 471 [1]. 
NOTE 2: The encoding of the fragment version is an 8-bit unsigned integer as specified in TS 102 471 [1]. 
NOTE 3: The "highjield_value" given here does not necessarily mean that the transport flow actually contains a 

fragment with identifier OxFFFFFF, it merely sets the upper limit for the identifier. See clause 4.8.5.4 (Index) of 

TS 102 822-3-2 [21] and discussion on "highjield_value". 
NOTE 4: The "highjield_value" given here does not necessarily mean that the transport flow actually contains a 

fragment with version OxFF, it merely sets the upper limit for the version. See clause 4.8.5.4 (Index) of 

TS 102 822-3-2 [21] and discussion on "high field value". 



Example of the sub index Structure 

Clause 8.2.1.4 (fragment locator references) of TS 102 471 [1] mandates the "fragment_locator" field of the "sub index" 
to hold the 16-bit identifier of the ESG container containing the referenced fragment in the transport flow represented 
by the "sub index" in question. 



The example below declares fragments delivered in the transport flow associated with the identifier "OxAC" (in the 
"ESG session partition declaration"). 

The set of fragments declared are the following set of identifier- version pairs { {OxOOABCDOO, 0x05}, {OxOOABCDOT, 
0x17}, {0x00ABCD12, 0x09} }. fragments with identifiers "OxOOABCDOO" and "OxOOABCDOT" are placed in the ESG 
container with identifier "0x1234", while the third fragment with identifier "0x00ABCD12", is placed in the ESG 
container with identifier "0x1235". (Naturally, both ESG containers are found in the transport flow identified by 
"OxAC"). 



Note that the declaration is ordered based on the fragment identifiers, see clause 8.2.1.3 (sub index structure) of 

TS 102 471 [1]. As each of the "sub indexes" represents only one transport flow and each "sub index" contains only one 

version of a particular fragment at a time, one only needs to sort the fragment identifiers in ascending order. 

Example instantiation of sub index structure: 

NOTE: the example given in this clause is for illustration purposes. Typically the sub index will hold many more 
entries. 
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Table 8-5: Simplified example of a sub index 



Field 


Hex value 


Field Length 
(bits) 


Mnemonic 


Description 


Decimal value 


leaf field 


"0" 


1 


bslbf 


Not used. Set to "0". 


multiplejocators 


"0" 


1 


bslbf 


Signals that each index entry has a single 
locator. 


reserved 


"111111" 


6 


bslbf 




field_value 


OxAC 
172 


8 


uismbf 


the identifier of the transport flow 
delivering the fragment referenced here. 


field_value 


OxOOABCDOO 
11259136 


32 


uismbf 
See note 1 


the identifier of the fragment referenced 
here. 


field_value 


0x0005 
5 


16 


uismbf 
See note 2 


the version of the fragment with identifier 
"OxOOABCDOO" referenced here. 


fragmentjocator 


0x1234 
4660 


16 


uismbf 


the identifier of the ESQ container 
containing the fragment referenced here. 


field_value 


OxAC 
172 


8 


uismbf 


the identifier of the transport flow 
delivering the fragment referenced here. 


field_value 


0X00ABCD07 
11259143 


32 


uismbf 
See note 1 


the identifier of the fragment referenced 
here. 


field_value 


0x0017 
23 


16 


uismbf 
See note 2 


the version of the fragment with identifier 
"0x00ABCD07" referenced here. 


fragmentjocator 


0x1234 
4660 


16 


uismbf 


the identifier of the ESG container 
containing the fragment referenced here. 


field_value 


OxAC 
172 


8 


uismbf 


the identifier of the transport flow 
delivering the fragment referenced here. 


field_value 


0X00ABCD12 
11259154 


32 


uismbf 
See note 1 


the identifier of the fragment referenced 
here. 


field_value 


0x0009 
9 


16 


uismbf 
See note 2 


the version of the fragment with identifier 
"0x00ABCD12" referenced here. 


fragmentjocator 


0x1235 
4661 


16 


uismbf 


the identifier of the ESG container 
containing the fragment referenced here. 


NOTE 1 : The encoding of the fragment identifier is 24-bit unsigned integer as specified in TS 102 471 [1]. 
NOTE 2: The encoding of fragment version is 8-bit unsigned integer as specified in TS 102 471 [1]. 



8.2.2.3 Strategy for grouping fragments into ESG containers 

This is as per the single- stream case. 

8.2.2.4 Partitioning 

The ESG data are spHt into a number of separate transport flows. A partitioning strategy is used to decide on the set of 
data to be carried in each transport flow. The particular partitioning strategy used and the set of transport flows that 
form this partitioned ESG are signalled within an ESG session partition declaration which is carried in the 
announcement carousel. 
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ESG Session Partition Declaration 



num_fields 



overlapping 



n_o_IPStreams 



IPVersion6 



field_identifier[k] 



field_encoding[k] 



field_length[k] 



num_fields 



IPStreamID 



if(IPVersion6) 



else 



ESGSourceAddress[i] 



IPAddress[i] 



ESGSourceAddress[i] 



IPAddress[i] 



Port[i] 



SessionlD[i] 



If (overlapping) 



|start_field_value[i][k] 



end_field_value[i][k] 



num fields 



n IPStreams 



e.g. time period, ServicelD.. 
e.g. String, Integer, float... 



Identifier of the ESG 
Transport Flow 



IPv6 Add r 



IPv4 Add r 



Minimum of the range of 
field values 



Maxiimum of the range of 
field values 



Figure 8-5: Structure of the ESG session partition declaration 
in the case of multiple stream transport 

The ESG session partition declaration may be keyed on a number of fields including: 

• The number of hours measured from now for which the fragments are relevant. This may be used to split the 
ESG into various time intervals. See below for an example. 

• The "servicelD" attribute of the target Service fragments. This may be used to carry all fragments relevant to a 
particular service. 

• User-defined keys. 

NOTE 1: Further fields specified in table 8.2 of TS 102 471 [1] for the partition strategy, such as for instance 
absolute time stamps are under discussion for an amendment of TS 102 471 [1]. 

The Usage of ESG Session Partition strategy: 

The number of hours for which the fragments are relevant. 

Using this rule, the ESG can be delivered according to various time schedules. The split such as to 2 hours, 2 hours to 
4 hours, 4 hours to 6 hours gives the terminal the opportunity of decoding the specific ESG part it wants. 

NOTE 2: If the terminal is interested in one partition, e.g. in the 2 to 4 hours time span, it might be required to also 
consume previous partitions, e.g. the to 2 hours partition, in this case, to receive fragments which for 
instance are referenced by fragments contained in those partitions, e.g. the service fragments. However it 
is assumed that a terminal in most cases already has consumed the previous partitions respectively 
sessions before entering a consecutive one. 

Each rule can be applied in duplicate manner. Thus, an ESG having a schedule with a 6 hours scope can be delivered as 
follows: to 2 hours, to 4 hours, to 6 hours. 

The URI declared in the servicelD attribute of the S service fragment. 

Using this rule, the ESG can be split based on servicelDs. 

NOTE 3: Ranges of strings which might be used for partitioning are specified according to alphabetical ordering of 
the strings. 
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When the terminal accesses the network for the first time, the terminal acquires the init container and discovers the ESG 
partition strategy. If the terminal connects a second time, it could estimate the transport flow in which a specific service 
is described using its local cached ESG session partition declaration. In addition, while observing the TOI allocated to 
the init container, terminals can detect the potential init container updates and therefore could decide whether to check 
the ESG session partition declaration in the init container, before using the locally cached ESG session partition 
declaration. 

The purpose of the "overlapping" field is to enable the declaration of ranges that are overlapping or are not connected. 
The "overlapping" field set to "1" forces the "start_field_value" and the "end_field_value" to be declared for each 
partitioning criteria. 

NOTE 4: If multiple partitioning criteria are signalled (i.e. num_fields > 1), it is recommended to set the 
"overlapping" field to "1". 

NOTE 5: It is recommended to signal the maximal possible range of a given criterion, if this particular criterion 
doesn't actually apply to a given ESG session. 

Example of a partition declaration with maximal possible range 

Figure 8-6 represents an example of using such maximal possible range values, where the "number of hours" 
(Field_identifier=OxOO) and the "servicelD" (Field_identifier=0x01) criteria are used for partitioning. It is assumed that 
a 24hours ESG is sent to the terminals using three transport flows, transport flows 1 and 3 address the same range of 
ServicelD signalled by start_field_value="dvbipdc://a", end_field_value="dvbipdc://v" which is in fact the range of 
ServicelD whose ServicelD according to lexicographical order is included between " dvbipdc://a" and " dvbipdc://v". 
The "number of hours" criterion is also applied to these two transport flows. Using these two transport flows, the 
24hours ESG data for ServicelDs included in range start_field_value="dvbipdc://a", end_field_value="dvbipdc://v" are 
divided into 0'-2, 2-- 24 hours periods, and transmitted to the terminals. For the transport flow 2, for which the "number 
of hours" criteria doesn't apply, it is recommended to use "start_field_value=0", "end_field_value"=OxFFFF". This 
transport flow actually contains all the fragments relevant to the services whose ServicelD is included in the range of 
ServicelD signalled by end_field_value="dvbipdc://v", end_field_value="dvbipdc://z", that is to say included between 
"dvbipdc://v" and "dvbipdc://z", regardless on time. 



IP stream=1 



IP stream=2 



Fieldjdentifier = 0x00 

Start_field_value=0 
End_field_value=0x0002 

Not applied 
Start_field_value=0 
End field value=OxFFFF 



Field_identifier = 0x01 

Start_field_value="dvbipdc://a" 
End_field_value=dvbipdc://v 

Start_field_value="dvbipdc://v" 
End_field_value="dvbipdc://z" 



IP stream=3 



Start_field_value=0x0002 
End field value=0x0018 



Start_field_value="dvbipdc://a" 
End_field_value="dvbipdc://v" 



Figure 8-6: Example of an ESG session partition declaration 

Figure 8-7 represents the example above, represented as a tree. 

ServiceJD The number of hours 

IP Stream =1 



ESG 
partitioning 



"dvbipdc://a" 
-"dvbipdc://v" 



0-2 



2-24 



"dvbipdc://v" 
-"dvbipdc://z" 



IP stream =3 



IP Stream =2 



Figure 8-7: The ESG session partition declaration example represented as a tree 
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Example of a partition declaration with one criterion and overlapping set to "true" 

In the following, example instantiations of the ESG session partition declaration are given, based on time intervals when 
the fragments are relevant. 

The first example describes an ESG with one day scope (24 hours) where time intervals boundaries are overlapping as 
follows: to 2 hours, and to 24 hours from present moment. 

The second example is otherwise identical, but with no overlaps, i.e. to 2 hours, and 2 to 24 hours from present. 

In both examples the partition has two blocks representing two IPv4 transport sessions in turn: 

Table 8-6: Example of a multiple stream configuration 



Transport Flow (Hex 
and decimal values) 


Source 


Destination 


Port 


OxAC 
172 


OxCAFEBABE 
202.254.186.190 


OxEEADBEEF 
238.173.190.239 


OxDEED 
57069 


OxBC 
188 


OxCAFEBABE 
202.254.186.190 


0xEEADBEE5 
238.173.190.238 


OxDEEF 
57071 



In table 8-7 an example of a partition declaration with overlapping partitions based on the number of hours is given: 
Table 8-7: Example of ESG session partition declaration with overlapping partition boundaries 



Field 


Hex value 


Field Length 
(bits) 


Mnemonic 


Description 


Decimal value 


numjields 


0x01 

1 


8 


uimsbf 


the number of criteria based on 
which the partition is formed. This 
is set to 0x01 indicating only one 
criterion, namely the validity 
interval of fragments. 


overlapping 


"1" 


1 


bslbf 


this is set to 1 indicating mutually 
overlapping partition strategy. 


reserved 


"1111111" 


7 


bslbf 


always set to one. 


fieldjdentifier 


0x0000 


16 


bslbf 


the identifier specifying the 
criteria to be used. Value 0x0000 
indicates relative time interval. 
See note. 


field_encoding 


0x0101 


16 


bslbf 


indicates the datatype used to 
represent the time interval. Value 
0x0101 indicates unsigned short 
16 bits representing the amount 
of hours the fragments of the 
session are relevant. See 
table 8.4 of [1]. 


fieldjength 


0x02 
2 


8 


uimsbf 


indicates the length in bytes of 
the datatype specified by 
field_encoding. For unsigned 
short this becomes 0x02. 


n_o_IPStreams 


0x02 
2 


8 


uimsbf 


the number of transport flows, 
i.e. transport sessions the 
partition represents. 


IPVersion6 


"0" 


1 


bslbf 


Boolean flag telling whether the 
transport sessions use IPv6 
address scheme. meaning that 
IPv4 is used in this example. 


Reserved 


"1111111" 


7 


bslbf 


always set to one. 


IPStreamID 


OxAC 
172 


8 


uimsbf 


the identifier the transport 
session is associated with. This 
identifier is further used in the 
indexing part as reference. 


ESGSourceAddress 


OxCAFEBABE 
202.254.186.190 


32 


bslbf 


the IP address of the source of 
the transport session. 


IPAddress 


OxEEADBEEF 
238.173.190.239 


32 


bslbf 


the IP address of the destination 
of the transport session. 
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Field 


Hex value 


Field Length 
(bits) 


Mnemonic 


Description 


Decimal value 


Port 


OxDEED 
57069 


16 


uimsbf 


the port number of the destination 
of the transport session. 


SessionID 


OxABBA 
43962 


16 


uimsbf 


the LCT transport session 
identifier of the transport session. 


start_field_value 


0x0000 


16 


uimsbf 


the start boundary of the 
represented criteria. In this case 
it declares the start point of the 
time interval for relevance of 
fragments (0x00 for the present 
time) carried by the transport flow 
OxAC. 


end_field_value 


0x0002 


16 


uimsbf 


the end boundary of the 
represented criteria. In this case 
it declares the end point of the 
time interval (2 hours from the 
present) for relevance of 
fragments carried by the 
transport flow OxAC. 


IPStreamID 


OxBC 
188 


8 


uimsbf 


the identifier the transport 
session is associated with. This 
identifier is further used in the 
indexing part as reference. 


ESGSourceAddress 


OxCAFEBABE 
202.254.186.190 


32 


bslbf 


the IP address of the source of 
the transport session. 


IPAddress 


0xEEADBEE5 
238.173.190.238 


32 


bslbf 


the IP address of the destination 
of the transport session. 


Port 


OxDEEF 
57071 


16 


uimsbf 


the port number of the destination 
of the transport session. 


SessionID 


OxABBB 
43963 


16 


uimsbf 


the LCT transport session 
identifier of the transport session. 


start_field_value 


0x0000 


16 


uimsbf 


the start boundary of the 
represented criteria. In this case 
it declares the start point of the 
time interval for relevance of 
fragments (0x00 for the present 
time) carried by the transport flow 
OxBC. 


end_field_value 


0x0018 


16 


uimsbf 


the end boundary of the 
represented criteria. In this case 
it declares the end point of the 
time interval (24 hours from the 
present) for relevance of 
fragments carried by the 
transport flow OxBC. 


NOTE: In the field identifier only the least significant 8-bits are interpreted as specified in TS 102 471 [1]. 
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Example of a partition declaration with one criterion and overlapping set to "false". 

Example with time boundaries without overlap. 

Table 8-8: Example of ESG session partition declaration without overlapping partition boundaries 



Field 


Hex value 


Field Length 
(bits) 


Mnemoni 
c 


Description 


Decimal value 


numjields 


0x01 

1 


8 


uimsbf 


the number of criteria based on which the partition 
is formed. This is set to 0x01 indicating only one 
criteria, namely the validity interval of fragments. 


overlapping 


"0" 


1 


bslbf 


this is set to indicating mutually exclusive 
partition strategy. 


reserved 


"1111111" 


7 


bslbf 


always set to one. 


fieldjdentifier 


0x0000 


16 


bslbf 


the identifier specifying the criteria to be used. 
Value 0x0000 indicates relative time interval. See 
note. 


field_encoding 


0x0101 


16 


bslbf 


indicates the datatype used to represent the time 
interval. Value 0x0101 indicates unsigned short 
16 bits representing the amount of hours the 
fragments of the session are valid. See table 8.4 of 
TS 102 471 [1]. 


fieldjength 


0x02 
2 


8 


uimsbf 


indicates the length in bytes of the datatype 
specified by field_encoding. For unsigned short the 
value is 0x02. 


n_o_IPStreams 


0x02 
2 


8 


uimsbf 


the number of transport flows, i.e. transport 
sessions the partition represents. 


IPVersion6 


"0" 


1 


bslbf 


Boolean flag telling whether the transport sessions 
use IPv6 address scheme. meaning that IPv4 is 
used in this example. 


reserved 


"1111111" 


7 


bslbf 


always set to one. 


IPStreamID 


OxAC 
172 


8 


uimsbf 


the identifier the transport session is associated 
with. This identifier is further used in the indexing 
part as reference. 


ESGSourceAddre 
ss 


OxCAFEBABE 
202.254.186.190 


32 


bslbf 


the IP address of the source of the transport 
session. 


IPAddress 


OxEEADBEEF 
238.173.190.239 


32 


bslbf 


the IP address of the destination of the transport 
session. 


Port 


OxDEED 
57069 


16 


uimsbf 


the port number of the destination of the transport 
session. 


SessionID 


OxABBA 
43962 


16 


uimsbf 


the LCT transport session identifier of the transport 
session. 


end_field_value 


0x0002 


16 


uimsbf 


the end boundary of the represented criteria. In this 
case it declares the end point of the time interval (2 
hours from the present) for relevance of fragments 
carried by the transport flow OxAC. 


IPStreamID 


OxBC 
188 


8 


uimsbf 


the identifier the transport session is associated 
with. This identifier is further used in the indexing 
part as reference. 


ESGSourceAddre 
ss 


OxCAFEBABE 
202.254.186.190 


32 


bslbf 


the IP address of the source of the transport 
session. 


IPAddress 


0XEEADBEE5 
238.173.190.238 


32 


bslbf 


the IP address of the destination of the transport 
session. 


Port 


OxDEEF 
57071 


16 


uimsbf 


the port number of the destination of the transport 
session. 


SessionID 


OxABBB 
43963 


16 


uimsbf 


the LCT transport session identifier of the transport 
session. 


end_field_value 


0x0018 


16 


uimsbf 


the end boundary of the represented criteria. In this 
case it declares the end point of the time interval 
(2 hours to 24 hours time range from the present, 
where the 2 hours is inferred from the 
end_field_value of the previous entry ) for 
relevance of fragments carried by the transport 
flow OxBC. 


NOTE: In the fieldjdentifier only the least significant 8-bits are interpreted as specified in TS 102 471 [1]. 
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Even though it is not recommended to set the overlapping field to "0" in a partition declaration with multiple criteria, an 
example of this case is given in clause 7.2.2.3. 



8.2.2.5 Strategy examples for grouping ESG containers into sessions 



Some general guidelines are: 

• The announcement carousel carrying the ESG session partition declaration and the optional 
fragment index should be carouselled at a rate that allows the contents of the carousel to be 
transferred during one DVB-H Bursts carrying ESG data. 

• The sessions carrying service fragments and acquisition fragments related to them should be 
repeated at a rate that allows the sessions to be transferred during one DVB-H Burst carrying 
ESG data. Remember that the order in which ESG containers are carried in a particular 
session is random. 

• ESG containers carrying data which change infrequently e.g. ESG auxiliary data like icons 
related to the services should be put into the session having maximal possible range of the 
time criterion. (This is the mechanism used to signal that the particular criterion does not 
apply to the given ESG session.) 

In order to support the caching by the terminal of a subset of the ESG, and also to support the phased storage of 
selected portions of the ESG, (for example, on power-up, we may want to store sufficient ESG data to allow 
Services to be played quickly), the time criteria for partition strategy may be used following this guideline: 

• A session carrying schedule events and their associated content fragments relating to the 
present schedule time and the immediate future should be carouselled at a high rate, in order 
to provide the short delays needed to support Now/Next applications. The schedule-related 
acquisition fragments should be also transported over this session. 

• As the time period to which schedule events and their associated content fragments are 
related increases, the rate at which the sessions carrying them are carouselled can be reduced: 
a request for schedule and content information for programs happening next week doesn't 
need the same response as a Now/Next query. 



8.3 ESG fragment encapsulation 



In order to support efficient delivery and processing of individual fragments, ESG fragments are encapsulated into ESG 
containers before being transported over a FLUTE session. 

NOTE 1: There are two types of identifiers of fragments with different scope specified in TS 102 471 [1]. The 
fragmented in the ESG fragment encapsulation is the id in the scope of the transport. The URI 
identifying the auxiliary data in an encapsulated auxiliary data fragment or the URI that identifies the 
given ESG XML fragment within the fragment itself is the id in the scope of the ESG datamodel. 

An ESG server should not change the URI that identifies a given ESG fragment (i.e. the URI that identifies the auxiliary 
data in an auxiliary data fragment, or the URI that identifies the given ESG XML fragment within the fragment itself) 
without, at the same time, changing the fragment_id that signals this ESG fragment in the fragment management 
information structure. 

Each ESG container is assigned a unique ID (Container_ID) and version information, which are signalled by the 
underlying ALC/FLUTE layer. It is recommended that each ESG container is announced in the FDT of the underlying 
FLUTE session with a URI having the following syntax: <"urn:dvb:ipdc:esg:cid">:<Container_ID>. 

The default and mandatory way to announce new versions of a ESG container, is to provide an FDT with a higher FDT 
instance ID as specified in the clause 8.1.2 of TS 102 471 [1]. The new FDT declares a new mapping of the ESG 
container's "Content-Location" field to a new TOI value. An optional way is to use the Split TOI mechanism. It consists 
in conveying the ESG container's container_ID and versionJD in the ESG container's TOI value. This allows the 
terminal to keep track of changes in ESG containers directly at the transport level, without the indirection of the FDT. 
This mechanism can be signalled in the FDT by the Version-ID-Length attribute as specified in clause 8.1.3 of 
TS 102 471 [1]. 



ETSI 



95 ETSI TS 1 02 592 V1 .1 .1 (2007-1 0) 

NOTE 2: FLUTE servers that implement the SpHt TOI mechanism should use the same Version-ID-Length 

attribute value for all the objects conveyed in the ESG fragment stream. If different Version-ID-Length 
values are used, FLUTE servers should avoid the creation of a TOI which could on the terminal side 
result in a wrong interpretation (for example a TOI which most significant bits are in conflict with those 
used e.g. by a different ESG container). The Version-ID-Length attribute should be set to a sufficiently 
high value to minimize the probability of wrap around of the Version_ID. 



In order to avoid the FDT instance ID wrap around problem, the Expires attribute of a given delivered FDT instance 
should be lower than the time the server will take to create 2^^ (2^^ = 524 288)19 new FDT instances after this given 
FDT instance (i.e. --6 days in case FDT instance is updated once a second). 



In this case IDs of two unexpired FDT instances can be compared using 20 bit signed arithmetic. FDT instance with ID 
A is newer than FDT instance with ID B, if A - B > 0. 

Under the condition that the files are received in the order they were send and the FullFDT flag in FDT instances are set 
to "true" the wraparound problem can be assumed not to exist because a received FDT instance with Full FDT attribute 
"true" always declares the latest consistent and complete set of files. 

For bandwidth saving purpose, ESG containers can be compressed with GZIP at transport level. This is signalled in the 
FDT by setting the "Content-Encoding" attribute to "gzip". 

There are three different types of ESG containers: 

• ESG init container: contains initialization information required by the client for setting up ESG reception and 
processing. 

• ESG fragment container: contains data related to the ESG (i.e. ESG XML fragments, ESG auxiliary data or 
private auxiliary data). 

• Optional ESG index container: contains indexing information for easily tracking changes to fragments without 
having to acquire all ESG fragment containers. 

The general structure of an ESG fragment container is given in figure 8-8. 



Header 



Fragment Mana- 
gement 
Information 



ESG Data 
Repository 



Figure 8-8: Generic structure of an ESG fragment container 

As shown in the figure 8-8, it consists of: 

• Header: which contains identification and pointers to the different high-level structures of the ESG fragment 
container. 

• Fragment management information structure: which holds identification information of the ESG fragments 
inside the ESG data repository, as well as pointers to them. 

• ESG data repository: which contains the ESG fragments (i.e. ESG XML fragments, ESG Auxiliary data or 
Private auxiliary data). 

NOTE 3: There should only ever be one fragment management information structure defined within a single ESG 
container as specified in TS 102 471 [1]. 

NOTE 4: When an ESG container encapsulates ESG auxiliary data or private auxiliary data (e.g. bitmaps, logos, 
etc.), a data repository structure of type string is added to the ESG container to declare the encoding, 
metadataURI and mimetype as specified in clauses 7.4.5 and 7.4.6 of TS 102 471 [1]. 
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NOTE 5: According to table 7.2 in TS 102 471 [1] it is only possible to signal one data repository and one ESG 
data repository in a single ESG container as the structure_id field in both cases is limited to "0x00". 

Figure 8-9 gives a simplified example of an ESG fragment container. The container is composed of two encapsulated 
ESG XML fragments. 
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Figure 8-9: Example of an ESG fragment container 

An encapsulated ESG XML fragment structure contains one ESG XML fragment (content, acquisition, etc.) represented 
according to the following options: 

• Textual XML as specified in clause 6.3.1 of TS 102 471 [1]. 

• Binary XML represented in the BiM format as specified in clause 6.3.2 of TS 102 471 [1]. 

The BiM format provides the highest compression efficiency and therefore its use is reasonable in constrained 
environments. 

NOTE 6: As stated for the semantics of the EncodingVersion in clause 6.2 of TS 102 471 [1], all ESG XML 

fragments of a given ESG are represented using the same format. Also in the multiple stream transport 
case this is valid as only one Decoderlnit is instantiated in the announcement session. 

For both representation options, the gzip compression at transport level is supported as specified in clause 8.1.1 of 
TS 102 471 [1]. 

In the context of textual representation, the gzip compression gives better results at transport (ESG container) level than 
at fragment level. 

The signalling of the representation of ESG XML fragments (textual, fragment level gzip, BiM) is carried in an ESG 
init message which is encapsulated in a special ESG container, called the ESG init container. The ESG init message 
holds all information necessary to set up the processing of ESG fragments at the client, in particular character encoding 
and Decoderlnit. 

The Decoderlnit is used to configure parameters required for the decoding and/or parsing of the ESG XML fragments 
and to transmit the initial state of the ESG document. The syntax of the Decoderlnit depends on the encoding used for 
the ESG XML fragments. The textual Decoderlnit applies to textual encoding and the BiM Decoderlnit to BiM 
encoding. They both permit to declare: 

• the namespaces used in the ESG data model; 

• ESG XML fragment types. 
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The declaration of ESG XML fragment types should only include ESG XML fragment types that are not already 
declared in table 6.2 of TS 102 471 [1]. 

The ESG init container may optionally contain an ESGMain element fragment in the case when the default ESGMain 
specified in clause 5.2.4 of TS 102 471 [1] should not be used by the decoder. Typically, the default ESGMain is used. 

8.4 Server side ESG processing 
8.4.1 ESG provisioning 

The ESG is provided to the terminal in multiple ESG containers. One of these ESG containers, the ESG init container, 
contains information for the terminal to initialize the reception of the ESG. The ESG init container gives: 

The encoding method used for the ESG. 

The indication if one or more indexes are carried within the stream. 

The Decoderlnit information. 

An optional ESGMain element. 

The ESG session partition declaration if the ESG multiple streams transport is used. 

The syntax of the Decoderlnit depends on the chosen encoding. In case of textual encoding the textual Decoderlnit is 
used as specified in TS 102 471 [1]. The following two clauses focus on the use of the textual Decoderlnit. 

8.4.1 .1 Textual decoderlnit 

The textual decoderlnit declares all namespaces referenced in the ESG XML fragments. This declaration is used to: 

• identify the namespaces and the corresponding prefixes used within the textual ESG XML fragments; 

• declare private fragment types. 

8.4.1 .2 Generation of textual ESG XML fragments 

A textual ESG XML fragment is represented within a ESG container as plain text or gzipped text. In the case of plain 
text, here is an example: 



<Service serviceID="BBCCBBC" f reeToAir="true" > 
<ServiceName>CBBC</ServiceName> 
<ServiceLogo> 

<mpeg7 : Titlelmage> 

<mpeg7 :MediaUri>logo/BBCCBBC .gif </mpeg7 :MediaUri> 
</mpeg7 : Titlelmage> 
</ServiceLogo> 
<ServiceType href =" urn: dvb : ipdc :esg: cs : ServiceTypeCS : 1 . 1"> 

<tva:Name xml : lang="en" >TV Service</tva :Name> 
</ServiceType> 

<AcquisitionRef IDRef ="BBCCBBC_acq"/> 
</Service> 



In order to address terminals that could require the XML namespaces to be declared within each ESG XML fragment 
(as it is specified in [20]), they may optionally be delivered as part of the ESG XML fragment, using the standard XML 
mechanisms. It is recommended that the namespaces and their prefixes match those declared within the textual 
Decoderlnit, and all relevant namespaces are declared within the ESG XML fragment. Find in the following an example 
of an ESG XML fragment including the namespace declaration. 
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< Service xmlns= 'urnrdvb: ipdc :esg: 2 005 ' xmlns :mpeg7= ' urn:mpeg:mpeg7 : schema: 2 001 ' 
xmlns : tva= 'urn: tva : metadata : 2 05 ' xmlns :xml= 'http: //www. w3 .org/XML/1998/namespace ' 
servicelD="BBCCBBC" f reeToAir="true" > 
<ServiceName>CBBC</ServiceName> 
<ServiceLogo> 

<mpeg7 : Titlelmage> 

<mpeg7 :MediaUri>logo/BBCCBBC .gif </mpeg7 :MediaUri> 
</mpeg7 : Titlelmage> 
</ServiceLogo> 
<ServiceType href =" urn: dvb : ipdc :esg: cs : ServiceTypeCS : 1 . 1"> 

<tva:Name xml : lang="en" >TV Service</tva :Name> 
</ServiceType> 

<AcquisitionRef IDRef ="BBCCBBC_acq"/> 
</Service> 



Additionally, for ESG XML fragments encoded in UTF-8 [22], it is recommend not to use the XML declaration at the 
beginning of the fragment, as authorized by the XML specification. 

8.4.2 Identifiers within ESG XML fragments 

An instance of a DVB-IPDC ESG data model uses URIs as specified in RFC 2396 [23] to uniquely identify fragments. 
In this clause the use of URIs is described to enable the compilation of ESGs of pre-existing ESG XML fragments. As 
the ESG XML fragments are processed at different stages of the service delivery as pointed out in TR 102 469 [38] , a 
URI format avoiding ambiguities is described in this clause. 

The URI used to identify ESG XML fragments may be of any URI type provided that there is no possible conflict 
between one fragment ID and another. As an example, the following URI format may avoid any conflict: 

dvbipdc://<domain_name>/<fragment_type>/<id> which domain name could be the service application domain name: 
example: dvbipdc://example.com/content/123456 



NOTE: 



a) The fragment ID is unique within the delivered ESG instance. It might be unique in a wider scope, 
depending of the server implementation. 

b) The only purpose of the URI in the fragment ID attributes is the identification. Do not expect that the 
terminal is resolving what is specified by this URI. 

c) The fragment ID, that this clause relates to, is the identifier instantiated within an ESG XML fragment in 
the ESG instance. It shall not be assimilated with the "fragmented" used in the ESG fragment 
management information defined in clause 7.3.1 of TS 102 471 [1]. 

d) It is recommended that the server only uses URIs with lower case characters to avoid confusion whether 
URI schemes are case sensitive or not. 



8.4.3 Referencing ESG auxiliary data 



ESG Auxiliary data are resources which are referenced from an instance of the XML based data model e.g. an SDP file, 
an HTML page, an SVG file, a PNG file, etc. 

A service provider may either make the ESG auxiliary data available: 

• As part of the data forming the ESG fragment stream. 

• Over the interactive channel. 

In the case that the ESG auxiliary data is available over the ESG fragment stream, the service provider should 
encapsulate the ESG auxiliary data as defined in TS 102 471 [1]. 

NOTE 1 : If HTML pages are transported as ESG auxiliary data also the referenced entities within the HTML page 
can be interpreted as ESG auxiliary data. Therefore the following is applicable to resolve the references to 
those entities. 
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NOTE 2: Even though SDP files can be considered as ESG auxiliary data, it is possible to transport them within the 
ESG fragment stream or as files within a FLUTE Session (see TS 102 591 [39] for further details). In 
both cases SDP files should be signalled using the MIME type "application/sdp". 

In order to speed up the process of accessing the ESG Auxiliary data in the terminal, it may be beneficial that the ESG 
auxiliary data, sent over the unidirectional ESG fragment stream, are transported in the same FLUTE session as the one 
conveying the ESG XML fragment(s) that refer to the given ESG auxiliary data. 

In the case where the ESG auxiliary data is available over the interactive channel, the URI identifying the resource 
should be a URL. However just because an ESG auxiliary data item is identified using a URL does not imply that the 
ESG auxiliary data is not delivered as a fragment within the ESG fragment stream (see clauses 7.5.2 and 7.5.3 for 
further information). In the case of URL schemes such as "rtsp", it is assumed that these are always hosted on the server 
side and so the ESG auxiliary data identified by the URL can not be delivered as fragments of the ESG fragment 
stream. 

In the case where the interactive channel is used: 

• Depending on the protocol that is used, servers may enable terminals to discover the characteristics of the 
given auxiliary data to fetch (e.g. mime type, codecs) and the associated delivery protocols (e.g. RTF transport 
features) via server responses to terminal requests. 

• It is recommended that network servers provide ESG auxiliary data that can be consumed by terminals 
complying to the IPDC over DVB-H specifications (e.g. using AA^ codecs defined in TS 102 005 [6], when 
appropriate). If the protocol that is used by the terminal to fetch the auxiliary data over the interactive channel 
supports the signalling and negotiation of terminal capabilities, the network server may adapt the ESG 
auxiliary data accordingly. 

Hereafter, we propose several examples of declarations of the "RelatedMaterial" element. In the first example, the target 
media asset is delivered in an ESG fragment container over the broadcast channel. In the second example the resource 
may be available within the ESG fragment stream or via the interactive channel. 

EXAMPLE 1 : The resource signalled by the RelatedMaterial element is an HTML page delivered over the 

broadcast channel, in which a recommendation for contents similar to the actual content is made. 

<Content contentID="dvbipdc : //example . com/Content3 " > 
<Title xml : lang="en">Content Item 3</Title> 
<Genre href = "urn: tva : metadata : cs : ContentCS : 2 005 : 1 .4 .5"/> 
<RelatedMaterial> 

<HowRelated href = ' urn: tva :metadata : cs :HowRelatedCS : 2007 : 6 ' /> 
<MediaLocator> 

<mpeg7 :MediaUri>recommandationf orContent3 .html</mpeg7 :MediaUri> 
</]y[ediaLocator> 
< /RelatedMaterial > 
<Duration>PT15M</Duration> 
</Content> 

EXAMPLE 2: The resource signalled by the RelatedMaterial element is an HTML page that gives more 

information about a given content. This resource may be available as an ESG auxiliary data 
fragment within the ESG fragment stream or over the interactive channel. 

<Content contentID="dvbipdc : //example . com/Content4 " > 
<Title xml :lang="en">Content Item 4</Title> 
<Genre href = "urn: tva : metadata : cs : ContentCS : 2 005 : 1 .4 .5"/> 
<RelatedMaterial> 

<HowRelated href= ' urn: tva :metadata : cs :HowRelatedCS : 2007 : 10 ' /> 
<MediaLocator> 

<mpeg7 :MediaUri>http : //www. example . com/Details/Content4 .html</mpeg7 :MediaUri> 
</MediaLocator> 
< /RelatedMaterial > 
<Duration>PT3 0M</Duration> 
</Content> 
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EXAMPLE 3: The resource signalled by the RelatedMaterial element is an A/V preview of the actual content that 
terminals can access over the interactive channel. 



<Content contentID="dvbipdc : //example . com/ContentS" > 
<Title xml : lang="en" >Content Item 5</Title> 
<Genre href = "urn: tva : metadata : cs : ContentCS : 2 005 : 1 .4 .5"/> 
<RelatedMaterial> 

<HowRelated href= ' urn: tva rmetadata : cs :HowRelatedCS : 2007 : 10 ' /> 
<MediaLocator> 

<mpeg7 :MediaUri>rtsp : //www. example . com/dvb/preview/Content5 .mp4</mpeg7 :MediaUri> 
</MediaLocator> 
< /RelatedMaterial > 
<Duration>PT3 0M</Duration> 
</Content> 



8.4.4 Time information within ESG XML fragments 

The availability of content is signalled in ScheduleE vents fragments in the ScheduleEventTable. For this purpose the 
ScheduleEvent fragments reference dedicated content fragments and signal the availability of the described content in 
the PublishedStartTime and PublishedEndTime elements. 

It is recommended that the PublishedStartTime and PublishedEndTime elements specify the time based on UTC as the 
UTC can be determined from the PSI/SI information in the DVB-H system TS 102 591 [39]. It is also recommended in 
this case to signal this explicitly by adding a "Z" to the dateTime string e.g. "2006-03-02T20:15:00Z". 

NOTE 1 : PublishedStartTime and PublishedEndTime can only be interpreted as time estimates when a schedule 
event takes place. Be aware that in IPDC version 1 no mapping to time stamps of the media delivered 
along the media is specified. Such a mapping is under consideration for a future version of the standard. 

NOTE 2: PublishedStartTime and PublishedEndTime used within the schedule event fragments only declare 

published times and so it is not recommended to use these values to control acquisition. These times are 
declared in UTC where the current time can be inferred from the TDT table available within the transport 
stream carrying the ESG service. In addition there is a sampling clock carried within RTCP sender reports 
that are used by the player to perform playout of the content. The "t=" fields in the SDP files may refer to 
this clock (see clause 5.1.2.1 of TS 102 591 [39]). The clock carried within RTCP sender reports may be 
independent of that signalled in the TDT. 

In the case the time is specified in a different time zone, the time zone is expected to be specified in the 
PublishedStartTime and PublishedEndTime elements according to the dateTime datatype definition in XML Schema 
[18]. 
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Annex A (normative): 
ParentalGuidance CS 



In this clause a ParentalGuidance classification schema is declared based on the rating systems as defined for the 
appropriate geographical region. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<Classif icationScheme uri= " urn : dvb : metadata : cs : Parent alGuidanceCS : 2 007" 
xmlns= "urn : dvb : metadata : schema : dvbCSschema : 2 7 " 
xmlns :xsi="http : //www. w3 . org/2001/XMLSchema-instance" 

xsi : schemaLocation=" urn: dvb: metadata: schema : dvbCSschema : 2 07 dvbCSschema .xsd" > 
<Term termID="l"> 

<Name xml : lang="en" >Australia</Name> 
<Definition xml : lang="en"/> 
<Term termID="l . 1" > 

<Name xml : lang="en" >iy[ovies and Game s< /Name > 

<Def inition>Movies and Games ratings as defined by the Australian Office of Film and 
Literature Classification ( http://www.oflc.gov.au ) < /Def ini t ion> 
<Term termID="l . 1 . 1" > 

<Name xml : lang="en" >E</Name> 

<Definition xml : lang="en" >Exempt From Classif ication</Def inition> 
</Term> 
<Term termID="l . 1 . 2 " > 

<Name xml : lang="en" >P</Name> 

<Definition xml : lang="en" >Suitable for All Ages</Def inition> 
</Term> 
<Term termID="l . 1 . 3 " > 

<Name xml : lang="en" >PG</Name> 

<Definition xml : lang="en" >Parental Guidance is Recommended for Young 
Viewers < /Def ini tion> 
</Term> 
<Term termID="l . 1 . 4" > 

<Name xml : lang="en" >M</Name> 

<Definition xml : lang="en" >Suitable for Mature Audiences</Def inition> 
</Term> 
<Term termID="l . 1 . 5" > 

<Name xml : lang="en" >MA15+</Name> 

<Definition xml : lang="en" >Suitable for Mature Audiences Only</Def inition> 
</Term> 
<Term termID="l . 1 . 6" > 

<Name xml : lang="en" >R18+</Name> 

<Definition xml : lang="en" >Restricted to Adults 18 Years and Over</Def inition> 
</Term> 
<Term termID="l . 1 . 7" > 

<Name xml : lang="en" >X18+</Name> 

<Definition xml : lang="en" >Restricted to Adults 18 Years and Over (ACT and NT Only) - 
Very Strong and Graphic Sex Scenes</Def inition> 
</Term> 
<Term termID="l . 1 . 8" > 

<Name xml : lang="en" >RC</Name> 

<Definition xml : lang="en" >Refused Classification </Def inition> 
</Term> 
</Term> 
<Term termID="l . 2 " > 

<Name xml : lang="en" >TV Programs</Name> 

<Definition> Movies and Games ratings as defined by the Australian Office of Film and 
Literature Classification ( http://www.oflc.gov.au ) </Def inition> 
<Term termID="l . 2 . 1" > 

<Name xml : lang="en" >P</Name> 

<Definition xml : lang="en" >Programmes suited specifically for pre-school 
children</Def inition> 
</Term> 
<Term termID="l . 2 . 2 " > 

<Name xml : lang="en" >C</Name> 

<Definition xml : lang="en" >Programmes suited for children 5 to 11 years of 
age</Def inition> 

</Term> 

<Term termID="l . 2 . 3 " > 

<Name xml : lang="en" >G</Name> 

<Definition xml : lang="en" >General Exhibition - Programmes which are suitable for all 
ages, but are not specifically geared towards children</Def inition> 
</Term> 
<Term termID="l . 2 . 4" > 
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<Name xml : lang="en">PG</Name> 

<Definition xml : lang="en" >Parental Guidance - Parental Guidance is recommended for 
young children. - Cannot be Shown between 4:00pm and 7:00pm on weekdays . </Definition> 
</Term> 
<Term termID="l . 2 . 5" > 

<Name xml : lang="en" >M</Name> 

<Definition xml : lang="en" >Mature - Recommended for Mature Audiences. - Can only be 
shown between 12:0 0pm - 3:00pm on School Days and 8:30pm - 5:00am any day</Def inition> 
</Term> 
<Term termID="l . 2 . 6" > 

<Name xml : lang="en" >MA15+</Name> 

<Definition xml : lang="en" >Mature Audience Only - Not suitable for Persons Under the 
Age of 15 . - Can only be shown between 9:00pm - 5:00am. A parental warning must be shown before the 
program starts</Def inition> 
</Term> 
<Term termID="l . 2 . 7" > 

<Name xml : lang="en" >AV15+</Name> 

<Definition xml : lang="en" >Adult Violence - Not Suitable for Persons Under the Age of 
15 - The AV 15+ signifies that the program contains significant violence</Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="2"> 

<Name xml : lang="en" >Belgium</Name> 
<Definition xml : lang="en"/> 
<Term termID="2 . 1" > 

<Name xml : lang="en" ></Name> 
<Term termID="2 . 1 . 1" > 

<Name xml : lang="nl" >KT< /Name > 

<Definition xml : lang="en" >Suitable for all</Def inition> 
</Term> 
<Term termID="2 . 1 . 2 " > 

<Name xml : lang="nl" >KNT< /Name > 

<Definition xml : lang="en" >Unsuitable for children</Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="3"> 

<Name xml : lang="en" >Brazil</Name> 
<Term termID="3 . 1" > 

<Name xml : lang="en" >Movies and Game s< /Name > 

<Definition xml : lang="en" > Movies and Games ratings as defined by the DJCTQ 

( http://www.mi.qov.br/classificacao ) </Definition> 

<Term termID="3 . 1 . 1" > 

<Name xml : lang="en" >General</Name> 

<Definition xml : lang="en" >This rating means that the film/game can be watched/played 
by anyone and doesn't have any inappropriate content</Def inition> 
</Term> 
<Term termID="3 . 1 . 2 " > 

<Name xml : lang="en" >12 years</Name> 

<Definition xml : lang="en" > This film/game is recommended for persons with or over 12 
years of age. May contain a little inappropriate language, sexual innuendo, or mild 
violence . </Def inition> 
</Term> 
<Term termID="3 . 1 . 3 " > 

<Name xml : lang="en" >14 years</Name> 

<Definition xml : lang="en" > This film/game is recommended for persons with or over 14 
years of age. May contain inappropriate language, sexual innuendo and/or mild sex with no nudity or 
the act being explicit shown, violence, mention to drug use . </Def inition> 
</Term> 
<Term termID="3 . 1 . 4" > 

<Name xml : lang="en" >16 years</Name> 

<Definition xml : lang="en" > This film/game is recommended for persons with or over 16 
years of age. May contain strong language, sexual innuendo and/or mild sex with or without mild 
nudity, strong violence, drug use. </Def inition> 
</Term> 
<Term termID="3 . 1 . 5" > 

<Name xml : lang="en" >18 years</Name> 

<Definition xml : lang="en" > This film/game is forbidden for people under 18 years of 
age. It may contain strong language, intense sex, strong nudity, strong violence, intense drug use. 
It is also used to rate pornographic films .. </Definition> 
</Term> 
</Term> 
</Term> 
<Term termID="4"> 

<Name xml : lang="en" >Canada</Name> 
<Definition xml : lang="en"/> 
</Term> 
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<Term termID="5"> 

<Name xml : lang="en" >Chile</Name> 
<Definition xml : lang="en"/> 
<Term termID="5 . 1" > 

<Name xml : lang="en" >The Council of Cinematographic Classif ication</Name> 
<Definition xml : lang="en" > Movie ratings as defined by the Consejo de Calif icacion 

cinematografica ( http://w3app.mineduc.cl/Conseio/index)</Definition > 

<Term termID="5 . 1 . 1" > 

<Name xml : lang="en" >TE</Name> 

<Definition xml : lang="en" >A11 Audiences</Def inition> 
</Term> 
<Term termID="5 . 1 . 2 " > 

<Name xml : lang="en" >14</Name> 

<Definition xml : lang="en" >Inappropriate for children under 14</Def inition> 
</Term> 
<Term termID="5 . 1 . 3 " > 

<Name xml : lang="en" >18</Name> 

<Definition xml : lang="en" >Suitable for people aged 18 and over</Def inition> 

<Term termID="5 . 1 . 3 . 1" > 

<Name xml : lang="en" >18/S</Name> 

<Definition xml : lang="en" >Suitable for people aged 18 and over with sexually 
explicit content</Def inition> 
</Term> 
<Term termID="5 . 1 . 3 . 2 " > 

<Name xml : lang="en" >18/V</Name> 

<Definition xml : lang="en" >Suitable for people aged 18 and over with extreme 
violence content</Def inition> 
</Term> 
</Term> 
</Term> 
</Term> 
<Term termID="6"> 

<Name xml : lang="en" >Colombia</Name> 
<Definition xml : lang="en"/> 
<Term termID="6 . 1" > 

<Name xml : lang="en" >The Ministry of Culture, Colombia</Name> 

<Definition xml : lang="en" > Movie ratings as defined by the Colombian Ministry of Culture 

( http://www.mincultura.qov.co ) </Definition > 

<Term termID="6 . 1 . 1" > 

<Name xml : lang="es" >T< /Name > 

<Definition xml : lang="en" >A11 Audiences</Def inition> 
</Term> 
<Term termID="6 . 1 . 2 " > 

<Name xml : lang="en" >7</Name> 

<Definition xml : lang="en" >Suitable for people aged 7 and over</Def inition> 
</Term> 
<Term termID="6 . 1 . 3 " > 

<Name xml : lang="en" >12</Name> 

<Definition xml : lang="en" >Suitable for people aged 12 and over</Def inition> 
</Term> 
<Term termID="6 . 1 . 4" > 

<Name xml : lang="en" >14</Name> 

<Definition xml : lang="en" >Suitable for people aged 14 and over</Def inition> 
</Term> 
<Term termID="6 . 1 . 5" > 

<Name xml : lang="en" >18</Name> 

<Definition xml : lang="en" >Suitable for people aged 18 and over</Def inition> 
</Term> 
<Term termID="6 . 1 . 6" > 

<Name xml : lang="en" >X</Name> 

<Definition xml : lang="en" >Pornographic Content</Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="7"> 

<Name xml : lang="en" >Denmark</Name> 
<Definition xml : lang="en"/> 
<Term termID="7 . 1" > 

<Name xml : lang="en" >The Media Council for Children and Young People</Name> 

<Definition xml : lang="en" >Scheme as defined by the Danish Media Council for Children 

and Young People ( http://www.medieraadet.dk/html/gb/qb.htm ) </Definition> 

<Term termID="7 . 1 . 1" > 

<Name xml : lang="en" >A</Name> 

<Definition xml : lang="en" >Approval of the film for general admittance</Def inition> 
</Term> 
<Term termID="7 . 1 . 2 " > 

<Name xml : lang="en" >7</Name> 
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<Definition xml : lang="en" >Approval of the film for general admittance, but not 
recommended for children under the age of 7</Def inition> 
</Term> 
<Term termID="7 . 1 . 3 " > 

<Name xml : lang="en" >11</Name> 

<Definition xml : lang="en" >Approval of the film for admittance of children from the 
age of ll</Def inition> 
</Term> 
<Term termID="7 . 1 . 4" > 

<Name xml : lang="en" >15</Name> 

<Definition xml : lang="en" >Approval of the film for admittance of children from the 
age of 15</Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="8"> 

<Name xml : lang="en" >Finland</Name> 
<Definition xml : lang="en"/> 
<Term termID="8 . 1" > 

<Name xml : lang="en" >Movies and Some Games</Name> 

<Definition xml : lang="en" >Scheme as defined by Finnish Board of Film Classification 

( http://www.vet.fi/english/board.htm i) </Def inition> 

<Term termID="8 . 1 . 1" > 

<Name xml : lang="en" >S</Name> 

<Definition xml : lang="en" >For all ages</Def inition> 
</Term> 
<Term termID="8 . 1 . 2 " > 

<Name xml : lang="en" >K-7</Name> 

<Definition xml : lang="en" >For people aged 7 years and above</Def inition> 
</Term> 
<Term termID="8 . 1 . 3 " > 

<Name xml : lang="en" >K-ll</Name> 

<Definition xml : lang="en" >For people aged 11 years and above</Def inition> 
</Term> 
<Term termID="8 . 1 . 4" > 

<Name xml : lang="en" >K-13</Name> 

<Definition xml : lang="en" >For people aged 13 years and above</Def inition> 
</Term> 
<Term termID="8 . 1 . 5" > 

<Name xml : lang="en" >K-15</Name> 

<Definition xml : lang="en" >For people aged 15 years and above</Def inition> 
</Term> 
<Term termID="8 . 1 . 6" > 

<Name xml : lang="en" >K-18</Name> 

<Definition xml : lang="en" >For people aged 18 years and above</Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="9"> 

<Name xml : lang="en" >France</Name> 
<Definition xml : lang="en"/> 
<Term termID="9 . 1" > 

<Name xml : lang="en" >Ministre of Culture</Name> 
<Term termID="9 . 1 . 1" > 

<Name xml : lang="en" >U</Name> 

<Definition xml : lang="en" >For all audiences</Def inition> 
</Term> 
<Term termID="9 . 1 . 2 " > 

<Name xml : lang="en" >-10</Name> 

<Definition xml : lang="en" >Unsuitable for minors under 10 or forbidden in cinemas for 
under 10s</Def inition> 
</Term> 
<Term termID="9 . 1 . 3 " > 

<Name xml : lang="en" >-12</Name> 

<Definition xml : lang="en" >Unsuitable for minors under 12 or forbidden in cinemas for 
under 12s</Def inition> 
</Term> 
<Term termID="9 . 1 . 4" > 

<Name xml : lang="en" >-16</Name> 

<Definition xml : lang="en" >Unsuitable for minors under 16 or forbidden in cinemas for 
under 16s</Def inition> 
</Term> 
<Term termID="9 . 1 . 5" > 

<Name xml : lang="en" >-18</Name> 

<Definition xml : lang="en" >Unsuitable for minors under 18 or forbidden in cinemas for 
under 18s</Def inition> 
</Term> 
</Term> 
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</Term> 

<Term termID="10"> 

<Name xml : lang="en" >Germany</Name> 
<Definition xml : lang="en"/> 
<Term termID="10 . 1" > 

<Name xml : lang="en" >Voluntary Self -Control of the Film Business, FSK</Name> 
<Definition xml : lang="en" >Scheme as defined by the Freiwillige Selbstkontrolle der 
Filmwirtschaft ( http://www.SpiO.de ) </Def inition> 

<Term termID="10 . 1 . 1" > 

<Name xml : lang="de" >FSK 0</Name> 

<Definition xml : lang="en" >For all ages</Def inition> 
</Term> 
<Term termID="10 . 1 . 2 " > 

<Name xml : lang="de" >FSK 6</Name> 

<Definition xml : lang="en" >No one under 6 years admitted</Def inition> 
</Term> 
<Term termID="10 . 1 . 3 " > 

<Name xml : lang="de" >FSK 12</Name> 

<Definition xml : lang="en" >People 12 or older admitted, children between 6 and 11 
only when accompanied by parent or legal guardian</Def inition> 
</Term> 
<Term termID="10 . 1 . 4" > 

<Name xml : lang="de" >FSK 16</Name> 

<Definition xml : lang="en" >People 16 or older admitted</Def inition> 
</Term> 
<Term termID="10 . 1 . 5" > 

<Name xml : lang="de" >FSK 18</Name> 

<Definition xml : lang="en" >Only adults (18 or older) admitted. Replaced by Keine 
Jugendf reigabe</Def inition> 
</Term> 
<Term termID="10 . 1 . 6" > 

<Name xml : lang="de">Keine Jugendf reigabe</Name> 

<Definition xml : lang="en" >"No youth admitted", only adults</Def inition> 
</Term> 
<Term termID="10 . 1 . 7" > 

<Name xml : lang="de" >SPIO/JK</Name> 

<Definition xml : lang="en" >Checked for possible violation against applicable law. Not 
rated by the FSK. It's legal to sell such a title to a person which is 18 or older</Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="ll"> 

<Name xml : lang="en" >Ireland</Name> 
<Definition xml : lang="en"/> 
<Term termID="ll . 1" > 

<Name xml : lang="en" >Irish Film Censor's Office (Movies) </Name> 

<Definition xml : lang="en" >Scheme as defined by the Irish Film Censor"s Office 
( http://www.ifco.ie ) </Def inition> 

<Term termID="ll . 1 . 1" > 

<Name xml : lang="en" >G</Name> 

<Definition xml : lang=" en" >' General ' - Suitable for viewing by anyone</Def inition> 
</Term> 
<Term termID="ll . 1 . 2 " > 

<Name xml : lang="en" >PG</Name> 

<Definition xml : lang=" en" >' Parental Guidance' - Parental guidance is recommended for 
children under the age of 12</Def inition> 
</Term> 
<Term termID="ll . 1 . 3 " > 

<Name xml : lang="en" >12A</Name> 

<Definition xml : lang="en" >Parent supervision required for children under 
12</Def inition> 

</Term> 

<Term termID="ll . 1 . 4" > 

<Name xml : lang="en" >15A</Name> 

<Definition xml : lang="en" >Parent supervision required for children under 
15</Def inition> 

</Term> 

<Term termID="ll . 1 . 5" > 

<Name xml : lang="en" >16</Name> 

<Definition xml : lang="en" >Films classified in this category are considered to be 
suitable for persons of 16 or over</Def inition> 
</Term> 
<Term termID="ll . 1 . 6" > 

<Name xml : lang="en" >18</Name> 

<Definition xml : lang="en" >Adults only</Def inition> 
</Term> 
</Term> 
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</Term> 

<Term termID="12"> 

<Name xml : lang="en" >Italy</Name> 
<Definition xml : lang="en"/> 
<Term termID="12 . 1" > 

<Name xml : lang="en" ></Name> 
<Term termID="12 . 1 . 1" > 

<Name xml : lang="en" >T</Name> 

<Definition xml : lang="en" >A11 admitted</Def inition> 
</Term> 
<Term termID="12 . 1 . 2 " > 

<Name xml : lang="en" >VM14</Name> 

<Definition xml : lang="en" >No one under the age of 14 admitted</Def inition> 
</Term> 
<Term termID="12 . 1 . 3 " > 

<Name xml : lang="en" >VM18</Name> 

<Definition xml : lang="en" >No one under the age of 18 admitted</Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="13"> 

<Name xml : lang="en" >Netherlands</Name> 
<Definition xml : lang="en"/> 
<Term termID="13 . 1" > 

<Name xml : lang="nl" >Kijkwij zer</Name> 

<Definition xml : lang="en" >Scheme as defined by the Kijkwijzer system 

( http://www.Kiikwiizer.n l) </Def inition> 

<Term termID="13 . 1 . 1" > 

<Name xml : lang="en" >AL</Name> 

<Definition xml : lang="en" >Suitable for all ages</Def inition> 
</Term> 
<Term termID="13 . 1 . 2 " > 

<Name xml : lang="en" >6</Name> 

<Definition xml : lang="en" >Not recommended for viewers younger than 6 
years </Definition> 
</Term> 
<Term termID="13 . 1 . 3 " > 

<Name xml : lang="en" >9</Name> 

<Definition xml : lang="en" >Not recommended for viewers younger than 9 
years </Definition> 
</Term> 
<Term termID="13 . 1 . 4" > 

<Name xml : lang="en" >12</Name> 

<Definition xml : lang="en" >Not recommended for viewers younger than 12 
years </Definition> 
</Term> 
<Term termID="13 . 1 . 5" > 

<Name xml : lang="en" >16</Name> 

<Definition xml : lang="en" >Movie shops/cinemas aren't allowed to show these movies to 
people younger than 16 years</Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="14"> 

<Name xml : lang="en" >Norway</Name> 
<Definition xml : lang="en"/> 
<Term termID="14 . 1" > 

<Name xml : lang="en" >The Norwegian Media Authority</Name> 
<Definition xml : lang="en" >Scheme as defined by the Medietilsynet 

( littp://www.medietilsvnet.no ) </Def inition> 

<Term termID="14 . 1 . 1" > 

<Name xml : lang="no" >Alle</Name> 

<Def inition xml : lang="en" ></Def inition> 
</Term> 
<Term termID="14 . 1 . 2 " > 

<Name xml : lang="en" >7</Name> 

<Def inition xml : lang="en" ></Def inition> 
</Term> 
<Term termID="14 . 1 . 3 " > 

<Name xml : lang="en" >11</Name> 

<Def inition xml : lang="en" ></Def inition> 
</Term> 
<Term termID="14 . 1 . 4" > 

<Name xml : lang="en" >15</Name> 

<Def inition xml : lang="en" ></Def inition> 
</Term> 
<Term termID="14 . 1 . 5" > 

<Name xml : lang="en" >18</Name> 
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<Def inition xml : lang="en" ></Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="15"> 

<Name xml : lang="en" >Portugal</Name> 
<Def inition xml : lang="en"/> 
<Term termID="15 . 1" > 

<Name xml : lang="en" >Ministre of Culture</Name> 

<Def inition xml : lang="en" > Scheme as defined by the Comissao de Classif icagao de 
Espectaculos ( http://www.CCe.Org.pt ) </Definition> 
<Term termID="15 . 1 . 1" > 

<Name xml : lang=" en ">!/[/ 4 < /Name > 

<Def inition xml : lang="en" >For persons of age 4 and above</Def inition> 
</Term> 
<Term termID="15 . 1 . 2 " > 

<Name xml : lang="en" >M/6</Name> 

<Def inition xml : lang="en" > For persons of age 6 and above</Def inition> 
</Term> 
<Term termID="15 . 1 . 3 " > 

<Name xml : lang="en" >]y[/12</Name> 

<Def inition xml : lang="en" > For persons of age 12 and above</Def inition> 
</Term> 
<Term termID="15 . 1 . 4" > 

<Name xml : lang="en" >M/16</Name> 

<Def inition xml : lang="en" > For persons of age 16 and above</Def inition> 
</Term> 
<Term termID="15 . 1 . 5" > 

<Name xml : lang="en" >]y[/18</Name> 

<Def inition xml : lang="en" > For persons of age 18 and above</Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="16"> 

<Name xml : lang="en" >South Korea</Name> 
<Def inition xml : lang="en"/> 
<Term termID="16 . 1" > 

<Name xml : lang="en" >Korea Media Rating Board</Name> 

<Def inition xml : lang="en" > Scheme as defined by the Korea Media Rating Board 

( http://www.kmrb.or.kr/english/statistics i.asp ) </Def inition> 

<Term termID="16 . 1 . 1" > 

<Name xml : lang="en" >A11</Name> 

<Def inition xml : lang="en" >Suitable for all ages</Def inition> 
</Term> 
<Term termID="16 . 1 . 2 " > 

<Name xml : lang="en" >12+</Name> 

<Def inition xml : lang="en" > Suitable for those aged 12 and over</Def inition> 
</Term> 
<Term termID="16 . 1 . 3 " > 

<Name xml : lang="en" >15+</Name> 

<Def inition xml : lang="en" > Suitable for those aged 15 and over</Def inition> 
</Term> 
<Term termID="16 . 1 . 4" > 

<Name xml : lang="en" >18+</Name> 

<Def inition xml : lang="en" > Suitable for those aged 18 and over</Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="17"> 

<Name xml : lang="en" >Spain</Name> 
<Def inition xml : lang="en"/> 
<Term termID="17 . 1" > 

<Name xml : lang="en" >Ministre of Culture</Name> 
<Term termID="17 . 1 . 1" > 

<Name xml : lang="en" >TP</Name> 

<Def inition xml : lang="en" >Suitable for the general public</Def inition> 
</Term> 
<Term termID="17 . 1 . 2 " > 

<Name xml : lang="en" >7</Name> 

<Def inition xml : lang="en" >Not recommended for people under 7</Def inition> 
</Term> 
<Term termID="17 . 1 . 3 " > 

<Name xml : lang="en" >10</Name> 

<Def inition xml : lang="en" > Not recommended for people under 10</Def inition> 
</Term> 
<Term termID="17 . 1 . 4" > 

<Name xml : lang="en" >13</Name> 

<Def inition xml : lang="en" > Not recommended for people under 13</Def inition> 
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</Term> 

<Term termID="17 . 1 . 5" > 

<Name xml : lang="en" >16</Name> 

<Definition xml : lang="en" > Not recommended for people under 16</Def inition> 
</Term> 
<Term termID="17 . 1 . 6" > 

<Name xml : lang="en" >18</Name> 

<Definition xml : lang="en" > Not recommended for people under 18</Def inition> 
</Term> 
<Term termID="17 . 1 . 7" > 

<Name xml : lang="en" >X</Name> 

<Definition xml : lang="en" >Strictly for adults</Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="18"> 

<Name xml : lang="en" >Sweden</Name> 
<Definition xml : lang="en"/> 
<Term termID="18 . 1" > 

<Name xml : lang="en" >Swedish National Board of Film Censors</Name> 
<Definition xml : lang="en" >Scheme as defined by Statens biografbyra 

( http://www.statensbioqrafbvra.se ) </Def inition> 

<Term termID="18 . 1 . 1" > 

<Name xml : lang="en" >Btl</Name> 

<Definition xml : lang="en" >Suitable for all ages</Def inition> 
</Term> 
<Term termID="18 . 1 . 2 " > 

<Name xml : lang="en" >7</Name> 

<Definition xml : lang="en" >Suitable for children of at least 7 years of 
age</Def inition> 

</Term> 

<Term termID="18 . 1 . 3 " > 

<Name xml : lang="en" >11</Name> 

<Definition xml : lang="en" >Suitable for children of at least 11 years of 
age</Def inition> 

</Term> 

<Term termID="18 . 1 . 4" > 

<Name xml : lang="en" >15</Name> 

<Definition xml : lang="en" >No one under 15 years of age admitted</Def inition> 
</Term> 
<Term termID="18 . 1 . 5" > 

<Name xml : lang="en" >18</Name> 

<Definition xml : lang="en" >No one under 18 years of age admitted</Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="19"> 

<Name xml : lang="en" >United Kingdom</Name> 
<Definition xml : lang="en"/> 
<Term termID="19 . 1" > 

<Name xml : lang="en" >British Board of Film Classif ication</Name> 

<Definition xml : lang="en" >Scheme as defined by the British Board of Film Classification 
( http://www.bbfC.CO.uk ) </Def inition> 
<Term termID="19 . 1 . 1" > 

<Name xml : lang="en" >Uc</Name> 

<Definition xml : lang="en" >Suitable for all but especially for young 
children</Def inition> 
</Term> 
<Term termID="19 . 1 . 2 " > 

<Name xml : lang="en" >U</Name> 

<Definition xml : lang="en" > Suitable for all</Def inition> 
</Term> 
<Term termID="19 . 1 . 3 " > 

<Name xml : lang="en" >PG</Name> 

<Definition xml : lang="en" > All ages admitted, but Parental Guidance is 
recommended</Def inition> 
</Term> 
<Term termID="19 . 1 . 4" > 

<Name xml : lang="en" >12A/12</Name> 

<Definition xml : lang="en" > No one under 12 years of age may see a "12A" film (unless 
accompanied by an adult) in a cinema or rent or buy a "12" video</Def inition> 
</Term> 
<Term termID="19 . 1 . 5" > 

<Name xml : lang="en" >15</Name> 

<Definition xml : lang="en" > No one under 15 years of age may see a "15" film or rent 
or buy a "15" video</Def inition> 
</Term> 
<Term termID="19 . 1 . 6" > 
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<Name xml : lang="en" >18</Name> 

<Definition xml : lang="en" > Suitable only for adults</Def inition> 
</Term> 
<Term termID="19 . 1 . 7" > 

<Name xml : lang="en" >R18</Name> 

<Definition xml : lang="en" > To be supplied only in licensed sex shops or cinemas to 
adults of not less than 18 years of age</Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="20"> 

<Name xml : lang="en" >United States</Name> 
<Definition xml : lang="en"/> 
<Term termID="20 . 1" > 

<Name xml : lang="en" >Motion Picture Association of America</Name> 

<Definition xml : lang="en" >Scheme for motion picture rating as defined by the Motion 
Picture Association of America ( http://www.mpaa.org/FilmRatings.asp ) </Definition> 
<Term termID="20 . 1 . 1" > 

<Name xml : lang="en" >G</Name> 

<Definition xml : lang="en" >General Audience - All ages admitted</Def inition> 
</Term> 
<Term termID="20 . 1 . 2 " > 

<Name xml : lang="en" >PG</Name> 

<Definition xml : lang="en" > Parental guidance suggested - Some material may not be 
suitable for young children</Def inition> 
</Term> 
<Term termID="20 . 1 . 3 " > 

<Name xml : lang="en" >PG-13</Name> 

<Definition xml : lang="en" > Parents strongly cautioned - Some material may be 
inappropriate for children under 13</Def inition> 
</Term> 
<Term termID="20 . 1 . 4" > 

<Name xml : lang="en" >R</Name> 

<Definition xml : lang="en" > Restricted - Under 17 requires accompanying parent or 
adult guardian</Def inition> 
</Term> 
<Term termID="20 . 1 . 5" > 

<Name xml : lang="en" >NC-17</Name> 

<Definition xml : lang="en" > No one 17 and under admitted</Def inition> 
</Term> 
<Term termID="20 . 1 . 6" > 

<Name xml : lang="en" >NR</Name> 

<Definition xml : lang="en" > Not an MPAA rating</Def inition> 
</Term> 
</Term> 
<Term termID="20 . 2 " > 

<Name xml : lang="en" >Entertainment Software Rating Board</Name> 

<Definition xml : lang="en" >Scheme for game rating as defined by the Entertainment 

Software Rating Board ( http://www.esrb.org/ratings/ratings guide. isp ) </Def inition> 

<Term termID="20 . 2 . 1" > 

<Name xml : lang="en" >ESRB Rating Symbol s< /Name > 

<Definition xml : lang="en" >Rating symbols suggest age appropriateness for the 
game</Def inition> 

<Term termID="20 . 2 . 1 . 1" > 

<Name xml : lang="en" >EC</Name> 

<Def inition>Titles rated EC (Early Childhood) have content that may be suitable 
for ages 3 and older. Contains no material that parents would find inappropriate</Def inition> 
</Term> 
<Term termID="20 . 2 . 1 . 2 " > 

<Name xml : lang="en" >E</Name> 

<Def inition>Titles rated E (Everyone) have content that may be suitable for ages 
6 and older. Titles in this category may contain minimal cartoon, fantasy or mild violence and/or 
infrequent use of mild language</Def inition> 
</Term> 
<Term termID="20 . 2 . 1 . 3 " > 

<Name xml : lang="en" >E10+</Name> 

<Definition> Titles rated E10+ (Everyone 10 and older) have content that may be 
suitable for ages 10 and older. Titles in this category may contain more cartoon, fantasy or mild 
violence, mild language and/or minimal suggestive themes</Def inition> 
</Term> 
<Term termID="20 . 2 . 1 . 4" > 

<Name xml : lang="en" >T</Name> 

<Definition> Titles rated T (Teen) have content that may be suitable for ages 13 
and older. Titles in this category may contain violence, suggestive themes, crude humour, minimal 
blood, simulated gambling, and/or infrequent use of strong language</Def inition> 
</Term> 
<Term termID="20 . 2 . 1 . 5" > 

<Name xml : lang="en" >M</Name> 
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<Definition> Titles rated M (Mature) have content that may be suitable for 
persons ages 17 and older. Titles in this category may contain intense violence, blood and gore, 
sexual content and/or strong language</Def inition> 
</Term> 
<Term termID="20 . 2 . 1 . 6" > 

<Name xml : lang="en" >AO</Name> 

<Definition> Titles rated AO (Adults Only) have content that should only be 
played by persons 18 years and older. Titles in this category may include prolonged scenes of 
intense violence and/or graphic sexual content and nudity</Def inition> 
</Term> 
<Term termID="20 . 2 . 1 . 7" > 

<Name xml : lang="en" >RP</Name> 

<Definition> Titles listed as RP (Rating Pending) have been submitted to the 
ESRB and are awaiting final rating. (This symbol appears only in advertising prior to a game's 
release) </Def inition> 

</Term> 
</Term> 
<Term termID="20 . 2 . 2 " > 

<Name xml : lang="en" >ESRB Content Descriptors</Name> 
<Definition xml : lang="en" >Content descriptors indicate elements in a game that may have 
triggered a particular rating and/or may be of interest or concern</Def inition> 
<Term termID="20 . 2 . 2 . 1" > 

<Name xml : lang="en" >Alcohol Ref erence</Name> 

<Def inition>Ref erence to and/or images of alcoholic beverages</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 2 " > 

<Name xml : lang="en" >Animated Blood</Name> 

<Def inition>Discoloured and/or unrealistic depictions of blood</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 3 " > 

<Name xml : lang="en" >Blood</Name> 
<Def inition>Depictions of blood</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 4 " > 

<Name xml : lang="en" >Blood and Gore</Name> 

<Def inition>Depictions of blood or the mutilation of body parts</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 5" > 

<Name xml : lang="en" >Cartoon Violence</Name> 

<Def inition>Violent actions involving cartoon-like situations and characters. 
May include violence where a character is unharmed after the action has been inf licted</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 6" > 

<Name xml : lang="en" >Comic Mischief </Name> 

<Def inition>Depictions or dialogue involving slapstick or suggestive 
humour</Def inition> 

</Term> 

<Term termID="20 . 2 . 2 . 7" > 

<Name xml : lang="en" >Crude Humour</Name> 

<Def inition>Depictions or dialogue involving vulgar antics, including 'bathroom" 
humour</Def inition> 

</Term> 

<Term termID="20 . 2 . 2 . 8" > 

<Name xml : lang="en" >Drug Ref erence</Name> 

<Definition>Ref erence to and/or images of illegal drugs</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 9" > 

<Name xml : lang="en" >Edutainment</Name> 

<Def inition>Content of product provides user with specific skills development or 
reinforcement learning within an entertainment setting. Skill development is an integral part of 
product</Def inition> 

</Term> 

<Term termID="20 . 2 . 2 . 10" > 

<Name xml : lang="en" >Fantasy Violence</Name> 

<Def inition>Violent actions of a fantasy nature, involving human or non-human 
characters in situations easily distinguishable from real lif e</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 11" > 

<Name xml : lang="en" >Inf ormational</Name> 

<Def inition>Overall content of product contains data, facts, resource 
information, reference materials or instructional text</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 12 " > 

<Name xml : lang="en" >Intense Violence</Name> 

<Def inition>Graphic and realistic-looking depictions of physical conflict. May 
involve extreme and/or realistic blood, gore, weapons and depictions of human injury and 
death</Def inition> 

</Term> 
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<Term termID="20 . 2 . 2 . 13 " > 

<Name xml : lang="en" >Language</Name> 

<Def inition>Mild to moderate use of prof anity</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 14 " > 

<Name xml : lang="en" >Lyrics</Name> 

<Def inition>Mild references to profanity, sexuality, violence, alcohol or drug 
use in music</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 15" > 

<Name xml : lang="en" >Mature Humour</Name> 

<Def inition>Depictions or dialogue involving "adult" humour, including sexual 
ref erences</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 16" > 

<Name xml : lang="en" >Mild Violence</Name> 

<Def inition>Mild scenes depicting characters in unsafe and/or violent 
situations</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 17" > 

<Name xml : lang="en" >Nudity</Name> 

<Def inition>Graphic or prolonged depictions of nudity</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 18" > 

<Name xml : lang="en" >Partial Nudity</Name> 

<Def inition>Brief and/or mild depictions of nudity</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 19" > 

<Name xml : lang="en" >Real Gambling</Name> 

<Def inition>Player can gamble, including betting or wagering real cash or 
currency</Def inition> 

</Term> 

<Term termID="20 . 2 . 2 . 20" > 

<Name xml : lang="en" >Sexual Themes</Name> 

<Def inition>Mild to moderate sexual references and/or depictions. May include 
partial nudity</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 21" > 

<Name xml : lang="en" >Sexual Violence</Name> 

<Def inition>Depictions of rape or other violent sexual acts</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 22 " > 

<Name xml : lang="en" >Simulated Gambling</Name> 

<Def inition>Player can gamble without betting or wagering real cash or 
currency</Def inition> 

</Term> 

<Term termID="20 . 2 . 2 . 23 " > 

<Name xml : lang="en" >Some Adult Assistance May Be Needed</Name> 

<Def inition>Intended for very young ages</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 24 " > 

<Name xml : lang="en" >Strong Language</Name> 

<Def inition>Explicit and/or frequent use of prof anity</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 25" > 

<Name xml : lang="en" >Strong Lyrics</Name> 

<Def inition>Explicit and/or frequent references to profanity, sex, violence, 
alcohol or drug use in music</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 26" > 

<Name xml : lang="en" >Strong Sexual Content</Name> 

<Def inition>Graphic references to and/or depictions of sexual behaviour, 
possibly including nudity</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 27" > 

<Name xml : lang="en" >Suggestive Themes</Name> 

<Def inition>Mild provocative references or materials</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 28" > 

<Name xml : lang="en" >Tobacco Ref erence</Name> 

<Def inition>Ref erence to and/or images of tobacco products</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 29" > 

<Name xml : lang="en" >Use of Drugs</Name> 

<Def inition>The consumption or use of illegal drugs</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 30" > 

<Name xml : lang="en" >Use of Alcohol</Name> 
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<Def inition>The consumption of alcoholic beverages</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 31" > 

<Name xml : lang="en" >Use of Tobacco</Name> 

<Def inition>The consumption of tobacco products</Def inition> 
</Term> 
<Term termID="20 . 2 . 2 . 32 " > 

<Name xml : lang="en" >Violence</Name> 

<Def inition>Scenes involving aggressive conf lict</Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="20 . 3 " > 

<Name xml : lang="en" > Recording Industry Association of America</Name> 

<Def inition>Scheme for music rating as defined by the Recording Industry Association of 

America ( http://www.riaa.com/issues/parents/advisorv.asp ) </Definition> 

<Term termID="20 . 3 . 1" > 

<Name xml : lang="en" >Parental Advisory</Name> 

<Def inition>The Parental Advisory is a notice to consumers that recordings 
identified by this value may contain strong language or depiction of violence, sex or substance 
abuse. Parental discretion is advised</Def inition> 
</Term> 
</Term> 
</Term> 
<Term termID="21"> 

<Name xml : lang="en" >Europe</Name> 
<Term termID="21 . 1" > 

<Name xml : lang="en" >Pan European Game Inf ormation</Name> 

<Definition xml : lang="en" >Scheme as defined by the Pan European Game Information 
( http://www.peqi.info ) </Def inition> 

<Term termID="21 . 1 . 1" > 

<Name xml : lang="en" >3+</Name> 

<Definition xml : lang="en" >Recommended for age 3 or over</Def inition> 
</Term> 
<Term termID="21 . 1 . 2 " > 

<Name xml : lang="en" >7+</Name> 

<Definition xml : lang="en" > Recommended for age 7 or over </Def inition> 
</Term> 
<Term termID="21 . 1 . 3 " > 

<Name xml : lang="en" >12+</Name> 

<Definition xml : lang="en" > Recommended for age 12 or over </Def inition> 
</Term> 
<Term termID="21 . 1 . 4" > 

<Name xml : lang="en" >16+</Name> 

<Definition xml : lang="en" > Recommended for age 16 or over </Def inition> 
</Term> 
<Term termID="21 . 1 . 5" > 

<Name xml : lang="en" >18+</Name> 

<Definition xml : lang="en" > Recommended for age 18 or over </Def inition> 
</Term> 
</Term> 
</Term> 
< /Class ificationScheme> 



ETSI 



113 



ETSI TS 102 592 VI .1.1 (2007-10) 



Annex B (normative): 
HowRelated CS 



In this clause a HowRelated classification schema is declared. For examples how to use it see clause 5.5.4. 

The following profile of the HowRelated classification Scheme specified in [33] with the relevant termlDs as listed in 
this annex should be used. 



termID 


Name 


Definition 


1 


Trailer 


By default, the reference points to a trailer of the currently described resource. 


1.2 


IsTrailerOf 


The reference points to a resource of which the currently described resource is a 
trailer. 


4 


Alternative 


The reference points to an alternative version of the current resource. 
EXAMPLE: Whilst watching a programme, or part of programme, the user is able 
to discover that a high definition version is available elsewhere. 


6 


Recommendation 


The reference points to a resource recommended the provider of the current 

resource. The service provider considers there to be similarities between the 

currently described resource and the referenced resource. 

EXAMPLE: This could provide access to previous or next episodes or to all 
episodes (the parent series as a whole). Suggestion to record a 
programme which the broadcaster recommends because of what 
the user is watching. It could also point to a Web site proposing 
related programmes recommended by the service provider. A 
recommendation can be used to suggest content or services or 
services bundles with a similar subject. 


8 


Commercial advert 


By default, the reference points to the advert for a product or service featured in 

the current resource. 

EXAMPLE: The user is watching a film containing a desirable product. If the 

user indicates interest in that product an advert is captured 

providing further information. 


8.1.2 


IsNormalAdvertOf 


The reference points to the resource advertised by the current normal advert. 


9 


Direct product purchase 


The reference points to a product or service directly linked to the current 
resource, which can be purchased directly from this linked resource. 
EXAMPLE: The user is watching a film containing a desirable product or 

service. (The recipe book from a cookery series for instance) If the 
user indicates interest in that product they are taken to a web page 
(or interactive application) which is able to fulfil their purchasing 
requirement. 


10 


For more information 


The reference points to additional information concerning the current resource in 
the form of audio/video/text/graphics/interactive app/web content. 
EXAMPLE: The user watching a programme for which the content provider has 
made available additional information. If the user indicates interest 
they are taken directly to that additional content and then returned 
to the original content. 


12 


Recap 


The reference points to a text or av recap of the resource. 
EXAMPLE: The user can chose to read/watch a recap if they have missed a 
previous episode or forgotten the thread of the series. 


13 


The making of 


By default, the reference points to the making-of of the current resource. 
EXAMPLE: "The user, if interested can view the background to how the 
programme was made". 


13.2 


IsMakingOfFor 


The reference points to the resource corresponding to the current making-of 


32 


Review Information 


By default the reference points to a review or critique of the resource that may be 
of interest to the user in deciding whether to continue to watch, download, etc. 
EXAMPLE: The user can look at the additional information and use it to decide 
whether to continue watching a programme. 


32.2 


IsReviewlnformationFor 


The reference points to the resource that is the subject of the review. 


33 


Preview 


By default, in complement to "Trailer", the reference points to a preview of the 
resource in a different format (e.g. longer sequences or interactive content) to 
assess e.g. previously advertised content or services. 


33.2 


IsPreviewOf 


The reference points to the resource addressed by the current preview. 
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Annex C (normative): 
Codec CS 



For the relevant audio and video codecs that are specified in TS 102 005 [6] the DVB VideoCodec classification 
Scheme [31] and DVB AudioCodec classification Scheme [32] should be referenced. 
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